-
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.6 (version in image is 15.6-150600.37.2).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: Memory safety bugs present in Firefox 141 and Thunderbird 141. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 142 and Thunderbird < 142.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- mozilla-nss-certs < 3.112.2-150400.3.60.1 (version in image is 3.112-150400.3.57.1).
-
Description: Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- bind-utils < 9.18.33-150600.3.18.1 (version in image is 9.18.33-150600.3.9.1).
-
Description: In specific circumstances, due to a weakness in the Pseudo Random Number Generator (PRNG) that is used, it is possible for an attacker to predict the source port and query ID that BIND will use.This issue affects BIND 9 versions 9.16.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.16.8-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- bind-utils < 9.18.33-150600.3.18.1 (version in image is 9.18.33-150600.3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right usernsWhat we want is to verify there is that clone won't expose somethinghidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo"may be a result of MNT_LOCKED on a child, but it may also come fromlacking admin rights in the userns of the namespace mount belongs to.clone_private_mnt() checks the former, but not the latter.There's a number of rather confusing CAP_SYS_ADMIN checks in varioususerns during the mount, especially with the new mount API; they servedifferent purposes and in case of clone_private_mnt() they usually,but not always end up covering the missing check mentioned above.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix handling of server side tls alertsScott Mayhew discovered a security exploit in NFS over TLS intls_alert_recv() due to its assumption it can read data fromthe msg iterator's kvec..kTLS implementation splits TLS non-data record payload betweenthe control message buffer (which includes the type such as TLSaler or TLS cipher change) and the rest of the payload (say TLSalert's level/description) which goes into the msg payload buffer.This patch proposes to rework how control messages are setup andused by sock_recvmsg().If no control message structure is setup, kTLS layer will read andprocess TLS data record types. As soon as it encounters a TLS controlmessage, it would return an error. At that point, NFS can setup akvec backed msg buffer and read in the control message such as aTLS alert. Msg iterator can advance the kvec pointer as a part ofthe copy process thus we need to revert the iterator before callinginto the tls_alert_recv.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix client side handling of tls alertsA security exploit was discovered in NFS over TLS in tls_alert_recvdue to its assumption that there is valid data in the msghdr'siterator's kvec.Instead, this patch proposes the rework how control messages aresetup and used by sock_recvmsg().If no control message structure is setup, kTLS layer will read andprocess TLS data record types. As soon as it encounters a TLS controlmessage, it would return an error. At that point, NFS can setup a kvecbacked control buffer and read in the control message such as a TLSalert. Scott found that a msg iterator can advance the kvec pointeras a part of the copy process thus we need to revert the iteratorbefore calling into the tls_alert_recv.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: reject malicious packets in ipv6_gso_segment()syzbot was able to craft a packet with very long IPv6 extension headersleading to an overflow of skb->transport_header.This 16bit field has a limited range.Add skb_reset_transport_header_careful() helper and use itfrom ipv6_gso_segment()WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151Modules linked in:CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151Call Trace: skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.9.1).
-
Description: Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()The function lio_target_nacl_info_show() uses sprintf() in a loop to printdetails for every iSCSI connection in a session without checking for thebuffer length. With enough iSCSI connections it's possible to overflow thebuffer provided by configfs and corrupt the memory.This patch replaces sprintf() with sysfs_emit_at() that checks for bufferboundries.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: sme: Use STR P to clear FFR context field in streaming SVE modeThe FFR is a predicate register which can vary between 16 and 256 bitsin size depending upon the configured vector length. When saving theSVE state in streaming SVE mode, the FFR register is inaccessible andso commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simplyclears the FFR field of the in-memory context structure. Unfortunately,it achieves this using an unconditional 8-byte store and so if the SMEvector length is anything other than 64 bytes in size we will eitherfail to clear the entire field or, worse, we will corrupt memoryimmediately following the structure. This has led to intermittent kfencesplats in CI [1] and can trigger kmalloc Redzone corruption messageswhen running the 'fp-stress' kselftest: | ============================================================================= | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten | ----------------------------------------------------------------------------- | | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531 | __kmalloc+0x8c/0xcc | do_sme_acc+0x9c/0x220 | ...Replace the 8-byte store with a store of a predicate register which hasbeen zero-initialised with PFALSE, ensuring that the entire field iscleared in memory.[1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: raid1: fix potential OOB in raid1_remove_disk()If rddev->raid_disk is greater than mddev->raid_disks, there will bean out-of-bounds in raid1_remove_disk(). We have already foundsimilar reports as follows:1) commit d17f744e883b ("md-raid10: fix KASAN warning")2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")Fix this bug by checking whether the "number" variable isvalid.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: handle backlogging of crypto requestsSince we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on ourrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, whenthe cryptd queue for AESNI is full (easy to trigger with anartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueuedto the backlog but still processed. In that case, the async callbackwill also be called twice: first with err == -EINPROGRESS, which itseems we can just ignore, then with err == 0.Compared to Sabrina's original patch this version uses the newtls_*crypt_async_wait() helpers and converts the EBUSY toEINPROGRESS to avoid having to modify all the error handlingpaths. The handling is identical.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: sync_linked_regs() must preserve subreg_defRange propagation must not affect subreg_def marks, otherwise thefollowing example is rewritten by verifier incorrectly whenBPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit(or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half).The following happens w/o this patch:- r0 is marked as not a subreg at (0);- w1 is marked as subreg at (2);- w1 subreg_def is overridden at (3) by copy_register_state();- w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set;- because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r));- this random value is read at (5).
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in crypt_message when using async cryptoThe CVE-2024-50047 fix removed asynchronous crypto handling fromcrypt_message(), assuming all crypto operations are synchronous.However, when hardware crypto accelerators are used, this can causeuse-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...);Hardware crypto modules often implement async AEAD operations forperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,the operation completes asynchronously. Without crypto_wait_req(),the function immediately frees the request buffer, leading to crasheswhen the driver later accesses the freed memory.This results in a use-after-free condition when the hardware cryptodriver later accesses the freed request structure, leading to kernelcrashes with NULL pointer dereferences.The issue occurs because crypto_alloc_aead() with mask=0 doesn'tguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC inthe mask, async implementations can be selected.Fix by restoring the async crypto handling:- DECLARE_CRYPTO_WAIT(wait) for completion tracking- aead_request_set_callback() for async completion notification- crypto_wait_req() to wait for operation completionThis ensures the request buffer isn't freed until the crypto operationcompletes, whether synchronous or asynchronous, while preserving theCVE-2024-50047 fix.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: libwx: remove duplicate page_pool_put_full_page()page_pool_put_full_page() should only be invoked when freeing Rx buffersor building a skb if the size is too short. At other times, the pagesneed to be reused. So remove the redundant page put. In the originalcode, double free pages cause kernel panic:[ 876.949834] __irq_exit_rcu+0xc7/0x130[ 876.949836] common_interrupt+0xb8/0xd0[ 876.949838] [ 876.949838] [ 876.949840] asm_common_interrupt+0x22/0x40[ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420[ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d[ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246[ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000[ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e[ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed[ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580[ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000[ 876.949852] ? cpuidle_enter_state+0xb3/0x420[ 876.949855] cpuidle_enter+0x29/0x40[ 876.949857] cpuidle_idle_call+0xfd/0x170[ 876.949859] do_idle+0x7a/0xc0[ 876.949861] cpu_startup_entry+0x25/0x30[ 876.949862] start_secondary+0x117/0x140[ 876.949864] common_startup_64+0x13e/0x148[ 876.949867] [ 876.949868] ---[ end trace 0000000000000000 ]---[ 876.949869] ------------[ cut here ]------------[ 876.949870] list_del corruption, ffffead40445a348->next is NULL[ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120[ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E)[ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi[ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary)[ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE[ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024[ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120[ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8[ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282[ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000[ 876.949942] RDX: 0000000000000105 RSI: 00000---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget : fix use-after-free in composite_dev_cleanup()1. In func configfs_composite_bind() -> composite_os_desc_req_prepare():if kmalloc fails, the pointer cdev->os_desc_req will be freed but notset to NULL. Then it will return a failure to the upper-level function.2. in func configfs_composite_bind() -> composite_dev_cleanup():it will checks whether cdev->os_desc_req is NULL. If it is not NULL, itwill attempt to use it.This will lead to a use-after-free issue.BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0Read of size 8 at addr 0000004827837a00 by task init/1CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()When gmin_get_config_var() calls efi.get_variable() and the EFI variableis larger than the expected buffer size, two behaviors combine to createa stack buffer overflow:1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure.2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded.The caller gmin_get_var_int() then performs:- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack- Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64- If EFI variable is >64 bytes, efi.get_variable() sets len=required_size- Due to bug #1, thinks call succeeded with len=required_size- Executes val[len] = 0, writing past end of 65-byte stack bufferThis creates a stack buffer overflow when EFI variables are larger than64 bytes. Since EFI variables can be controlled by firmware or systemconfiguration, this could potentially be exploited for code execution.Fix the bug by returning proper error codes from gmin_get_config_var()based on EFI status instead of stale 'ret' value.The gmin_get_var_int() function is called during device initializationfor camera sensor configuration on Intel Bay Trail and Cherry Trailplatforms using the atomisp camera stack.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Detect events pointing to unexpected TREsWhen a remote device sends a completion event to the host, it contains apointer to the consumed TRE. The host uses this pointer to process all ofthe TREs between it and the host's local copy of the ring's read pointer.This works when processing completion for chained transactions, but canlead to nasty results if the device sends an event for a single-elementtransaction with a read pointer that is multiple elements ahead of thehost's read pointer.For instance, if the host accesses an event ring while the device isupdating it, the pointer inside of the event might still point to an oldTRE. If the host uses the channel's xfer_cb() to directly free the bufferpointed to by the TRE, the buffer will be double-freed.This behavior was observed on an ep that used upstream EP stack without'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after bufferis written")'. Where the device updated the events ring pointer beforeupdating the event contents, so it left a window where the host was able toaccess the stale data the event pointed to, before the device had thechance to update them. The usual pattern was that the host received anevent pointing to a TRE that is not immediately after the last processedone, so it got treated as if it was a chained transaction, processing allof the TREs in between the two read pointers.This commit aims to harden the host by ensuring transactions where theevent points to a TRE that isn't local_rp + 1 are chained.[mani: added stable tag and reworded commit message]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: include node references in rose_neigh refcountCurrent implementation maintains two separate reference countingmechanisms: the 'count' field in struct rose_neigh tracks references fromrose_node structures, while the 'use' field (now refcount_t) tracksreferences from rose_sock.This patch merges these two reference counting systems using 'use' fieldfor proper reference management. Specifically, this patch adds incrementingand decrementing of rose_neigh->use when rose_neigh->count is incrementedor decremented.This patch also modifies rose_rt_free(), rose_rt_device_down() androse_clear_route() to properly release references to rose_neigh objectsbefore freeing a rose_node through rose_remove_node().These changes ensure rose_neigh structures are properly freed only whenall references, including those from rose_node structures, are released.As a result, this resolves a slab-use-after-free issue reported by Syzbot.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"and then dereferences it on the next line. Two lines later, we takea mutex so I don't think this is an RCU safe region. Re-order it to dothe dereferences before queuing up the free.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().smc_clc_prfx_set() is called during connect() and not under RCUnor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()after kernel_getsockname().Note that the returned value of smc_clc_prfx_set() is not usedin the caller.While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()not to touch dst there.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- tar > 0-0 (version in image is 1.34-150000.3.34.1).
-
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).
-
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).
-
Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- glib2-tools > 0-0 (version in image is 2.78.6-150600.4.16.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check S1G action frame sizeBefore checking the action code, check that it evenexists in the frame.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libxslt1 < 1.1.34-150400.3.13.1 (version in image is 1.1.34-150400.3.6.1).
-
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- containerd > 0-0 (version in image is 1.7.27-150000.123.1).
-
Description: golang-jwt is a Go implementation of JSON Web Tokens. Starting in version 3.2.0 and prior to versions 5.2.2 and 4.5.2, the function parse.ParseUnverified splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. This issue is fixed in 5.2.2 and 4.5.2.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/sev: Evict cache lines during SNP memory validationAn SNP cache coherency vulnerability requires a cache line evictionmitigation when validating memory after a page state change to private.The specific mitigation is to touch the first and last byte of each 4Kpage that is being validated. There is no need to perform the mitigationwhen performing a page state change to shared and rescinding validation.CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bitthat, when set, indicates that the software mitigation for thisvulnerability is not needed.Implement the mitigation and invoke it when validating memory (making itprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNPguest is vulnerable.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Prevent VMA split of buffer mappingsThe perf mmap code is careful about mmap()'ing the user page with theringbuffer and additionally the auxiliary buffer, when the event supportsit. Once the first mapping is established, subsequent mapping have to usethe same offset and the same size in both cases. The reference counting forthe ringbuffer and the auxiliary buffer depends on this being correct.Though perf does not prevent that a related mapping is split via mmap(2),munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,which take reference counts, but then the subsequent perf_mmap_close()calls are not longer fulfilling the offset and size checks. This leads toreference count leaks.As perf already has the requirement for subsequent mappings to match theinitial mapping, the obvious consequence is that VMA splits, caused byresizing of a mapping or partial unmapping, have to be prevented.Implement the vm_operations_struct::may_split() callback and returnunconditionally -EINVAL.That ensures that the mapping offsets and sizes cannot be changed after thefact. Remapping to a different fixed address with the same size is stillpossible as it takes the references for the new mapping and drops those ofthe old mapping.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix null pointer dereference on zero-length checksumIn xdr_stream_decode_opaque_auth(), zero-length checksum.len causeschecksum.data to be set to NULL. This triggers a NPD when accessingchecksum.data in gss_krb5_verify_mic_v2(). This patch ensures thatthe value of checksum.len is not less than XDR_UNIT.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
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-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libexpat1 < 2.7.1-150400.3.31.1 (version in image is 2.7.1-150400.3.28.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a zip bomb to be used to execute a DoS against the AIOHTTP server. An attacker may be able to send a compressed request that when decompressed by AIOHTTP could exhaust the host's memory. This issue is fixed in version 3.13.3.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow for an infinite loop to occur when assert statements are bypassed, resulting in a DoS attack when processing a POST body. If optimizations are enabled (-O or PYTHONOPTIMIZE=1), and the application includes a handler that uses the Request.post() method, then an attacker may be able to execute a DoS attack with a specially crafted message. This issue is fixed in version 3.13.3.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a request to be crafted in such a way that an AIOHTTP server's memory fills up uncontrollably during processing. If an application includes a handler that uses the Request.post() method, an attacker may be able to freeze the server by exhausting the memory. This issue is fixed in version 3.13.3.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. In versions 3.13.2 and below, handling of chunked messages can result in excessive blocking CPU usage when receiving a large number of chunks. If an application makes use of the request.read() method in an endpoint, it may be possible for an attacker to cause the server to spend a moderate amount of blocking CPU time (e.g. 1 second) while processing the request. This could potentially lead to DoS as the server would be unable to handle other requests during that time. This issue is fixed in version 3.13.3.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: Querying for records within a specially crafted zone containing certain malformed DNSKEY records can lead to CPU exhaustion.This issue affects BIND 9 versions 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- bind-utils < 9.18.33-150600.3.18.1 (version in image is 9.18.33-150600.3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: handle data disappearing from under the TLS ULPTLS expects that it owns the receive queue of the TCP socket.This cannot be guaranteed in case the reader of the TCP socketentered before the TLS ULP was installed, or uses some non-standardread API (eg. zerocopy ones). Replace the WARN_ON() and a buggyearly exit (which leaves anchor pointing to a freed skb) with realerror handling. Wipe the parsing state and tell the reader to retry.We already reload the anchor every time we (re)acquire the socket lock,so the only condition we need to avoid is an out of bounds read(not having enough bytes in the socket for previously parsed record len).If some data was read from under TLS but there's enough in the queuewe'll reload and decrypt what is most likely not a valid TLS record.Leading to some undefined behavior from TLS perspective (corruptinga stream? missing an alert? missing an attack?) but no kernel crashshould take place.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- python3-PyJWT > 0-0 (version in image is 2.4.0-150200.3.8.1).
-
Description: containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- containerd < 1.7.29-150000.128.1 (version in image is 1.7.27-150000.123.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix out of bounds read in smb2_sess_setupksmbd does not consider the case of that smb2 session setup isin compound request. If this is the second payload of the compound,OOB read issue occurs while processing the first payload inthe smb2_sess_setup().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- glib2-tools > 0-0 (version in image is 2.78.6-150600.4.16.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktlsWhen sending plaintext data, we initially calculated the correspondingciphertext length. However, if we later reduced the plaintext data lengthvia socket policy, we failed to recalculate the ciphertext length.This results in transmitting buffers containing uninitialized data duringciphertext transmission.This causes uninitialized bytes to be appended after a complete"Application Data" packet, leading to errors on the receiving end whenparsing TLS record.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: No more self recoveryWhen a node withdraws and it turns out that it is the only node that hasthe filesystem mounted, gfs2 currently tries to replay the local journalto bring the filesystem back into a consistent state. Not only is thata very bad idea, it has also never worked because gfs2_recover_func()will refuse to do anything during a withdraw.However, before even getting to this point, gfs2_recover_func()dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free beforecommit 04133b607a78 ("gfs2: Prevent double iput for journal on error")and is a NULL pointer dereference since then.Simply get rid of self recovery to fix that.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject duplicate device on updatesA chain/flowtable update with duplicated devices in the same batch ispossible. Unfortunately, netdev event path only removes the firstdevice that is found, leaving unregistered the hook of the duplicateddevice.Check if a duplicated device exists in the transaction batch, bail outwith EEXIST in such case.WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.1.3).
-
Description: An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the `h->nets` array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211_hwsim: Fix possible NULL dereferenceIn a call to mac80211_hwsim_select_tx_link() the sta pointer mightbe NULL, thus need to check that it is not NULL before accessing it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: jfs_dmap: Validate db_l2nbperpage while mountingIn jfs_dmap.c at line 381, BLKTODMAP is used to get a logical blocknumber inside dbFree(). db_l2nbperpage, which is the log2 number ofblocks per page, is passed as an argument to BLKTODMAP which uses itfor shifting.Syzbot reported a shift out-of-bounds crash because db_l2nbperpage istoo big. This happens because the large value is set without anyvalidation in dbMount() at line 181.Thus, make sure that db_l2nbperpage is correct while mounting.Max number of blocks per page = Page size / Min block size=> log2(Max num_block per page) = log2(Page size / Min block size) = log2(Page size) - log2(Min block size)=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: use RCU for hci_conn_params and iterate safely in hci_synchci_update_accept_list_sync iterates over hdev->pend_le_conns andhdev->pend_le_reports, and waits for controller events in the loop body,without holding hdev lock.Meanwhile, these lists and the items may be modified e.g. byle_scan_cleanup. This can invalidate the list cursor or any other itemin the list, resulting to invalid behavior (eg use-after-free).Use RCU for the hci_conn_params action lists. Since the loop bodies inhci_sync block and we cannot use RCU or hdev->lock for the whole loop,copy list items first and then iterate on the copy. Only the flags fieldis written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee weread valid values.Free params everywhere with hci_conn_params_free so the cleanup isguaranteed to be done properly.This fixes the following, which can be triggered e.g. by BlueZ newmgmt-tester case "Add + Remove Device Nowait - Success", or by changinghci_le_set_cig_params to always return false, and running iso-tester:==================================================================BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014Workqueue: hci0 hci_cmd_sync_workCall Trace:dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107)print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65)? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)kasan_report (mm/kasan/report.c:538)? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780)? mutex_lock (kernel/locking/mutex.c:282)? __pfx_mutex_lock (kernel/locking/mutex.c:282)? __pfx_mutex_unlock (kernel/locking/mutex.c:538)? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861)hci_cmd_sync_work (net/bluetooth/hci_sync.c:306)process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399)worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538)? __pfx_worker_thread (kernel/workqueue.c:2480)kthread (kernel/kthread.c:376)? __pfx_kthread (kernel/kthread.c:331)ret_from_fork (arch/x86/entry/entry_64.S:314)Allocated by task 31:kasan_save_stack (mm/kasan/common.c:46)kasan_set_track (mm/kasan/common.c:52)__kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383)hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277)hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589)hci_connect_cis (net/bluetooth/hci_conn.c:2266)iso_connect_cis (net/bluetooth/iso.c:390)iso_sock_connect (net/bluetooth/iso.c:899)__sys_connect (net/socket.c:2003 net/socket.c:2020)__x64_sys_connect (net/socket.c:2027)do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)Freed by task 15:kasan_save_stack (mm/kasan/common.c:46)kasan_set_track (mm/kasan/common.c:52)kasan_save_free_info (mm/kasan/generic.c:523)__kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244)__kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800)hci_conn_params_del (net/bluetooth/hci_core.c:2323)le_scan_cleanup (net/bluetooth/hci_conn.c:202)process_one_work (./arch/x86/include/asm/preempt.---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_createWe can't simply free the connector after calling drm_connector_init on it.We need to clean up the drm side first.It might not fix all regressions from commit 2b5d1c29f6c4("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"),but at least it fixes a memory corruption in error handling related tothat commit.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211_hwsim: drop short framesWhile technically some control frames like ACK are shorter andend after Address 1, such frames shouldn't be forwarded throughwmediumd or similar userspace, so require the full 3-addressheader to avoid accessing invalid memory if shorter frames arepassed in.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Add AML_NO_OPERAND_RESOLVE flag to TimerACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.=============================================================UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'CPU: 37 PID: 1678 Comm: cat Not tainted6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64kHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix hci_suspend_sync crashIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifiermay still be accessing it, it can cause the program to crash.Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1This patch holds the reference count of the hci_dev object whileprocessing it in hci_suspend_notifier to avoid potential crashcaused by the race condition.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: delete timer and free skb queue when unloadingFix possible crash and memory leak on driver unload by deletingTX purge timer and freeing C2H queue in 'rtw_core_deinit()',shrink critical section in the latter by freeing COEX queueout of TX report lock scope.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix out-of-bounds when setting channels on removeIf we set channels greater during iavf_remove(), and waiting reset donewould be timeout, then returned with error but changed num_active_queuesdirectly, that will lead to OOB like the following logs. Because thenum_active_queues is greater than tx/rx_rings[] allocated actually.Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) waitResult:[ 3506.152887] iavf 0000:41:02.0: Removing device[ 3510.400799] ==================================================================[ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf][ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536[ 3510.400823][ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1[ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021[ 3510.400835] Call Trace:[ 3510.400851] dump_stack+0x71/0xab[ 3510.400860] print_address_description+0x6b/0x290[ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf][ 3510.400868] kasan_report+0x14a/0x2b0[ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf][ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf][ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf][ 3510.400891] ? wait_woken+0x1d0/0x1d0[ 3510.400895] ? notifier_call_chain+0xc1/0x130[ 3510.400903] pci_device_remove+0xa8/0x1f0[ 3510.400910] device_release_driver_internal+0x1c6/0x460[ 3510.400916] pci_stop_bus_device+0x101/0x150[ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20[ 3510.400924] pci_iov_remove_virtfn+0x187/0x420[ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10[ 3510.400929] ? pci_get_subsys+0x90/0x90[ 3510.400932] sriov_disable+0xed/0x3e0[ 3510.400936] ? bus_find_device+0x12d/0x1a0[ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e][ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e][ 3510.400968] ? pci_get_device+0x7c/0x90[ 3510.400970] ? pci_get_subsys+0x90/0x90[ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210[ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10[ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e][ 3510.401001] sriov_numvfs_store+0x214/0x290[ 3510.401005] ? sriov_totalvfs_show+0x30/0x30[ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10[ 3510.401011] ? __check_object_size+0x15a/0x350[ 3510.401018] kernfs_fop_write+0x280/0x3f0[ 3510.401022] vfs_write+0x145/0x440[ 3510.401025] ksys_write+0xab/0x160[ 3510.401028] ? __ia32_sys_read+0xb0/0xb0[ 3510.401031] ? fput_many+0x1a/0x120[ 3510.401032] ? filp_close+0xf0/0x130[ 3510.401038] do_syscall_64+0xa0/0x370[ 3510.401041] ? page_fault+0x8/0x30[ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 3510.401073] RIP: 0033:0x7f3a9bb842c0[ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: call disconnect callback before deleting connIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.ISO, L2CAP and SCO connections refer to the hci_conn withouthci_conn_get, so disconn_cfm must be called so they can clean up theirconn, otherwise use-after-free occurs.ISO:==========================================================iso_sock_connect:880: sk 00000000eabd6557iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da...iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073hci_dev_put:1487: hci0 orig refcnt 17__iso_chan_add:214: conn 00000000b6251073iso_sock_clear_timer:117: sock 00000000eabd6557 state 3...hci_rx_work:4085: hci0 Event packethci_event_packet:7601: hci0: event 0x0fhci_cmd_status_evt:4346: hci0: opcode 0x0406hci_cs_disconnect:2760: hci0: status 0x0chci_sent_cmd_data:3107: hci0 opcode 0x0406hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560hci_conn_unlink:1102: hci0: hcon 000000001696f1fdhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2hci_chan_list_flush:2780: hcon 000000001696f1fdhci_dev_put:1487: hci0 orig refcnt 21hci_dev_put:1487: hci0 orig refcnt 20hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c... ...iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557BUG: kernel NULL pointer dereference, address: 0000000000000668PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTIHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth==========================================================L2CAP:==================================================================hci_cmd_status_evt:4359: hci0: opcode 0x0406hci_cs_disconnect:2760: hci0: status 0x0chci_sent_cmd_data:3085: hci0 opcode 0x0406hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585hci_conn_unlink:1102: hci0: hcon ffff88800c999000hci_chan_list_flush:2780: hcon ffff88800c999000hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280...BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfx___lock_acquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? __pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7ff45cb23e64Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: stop recv() if initial process_rx_list gave us non-DATAIf we have a non-DATA record on the rx_list and another record of thesame type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATAJust check the record type and jump to the end in case process_rx_listdid some work.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: interface: fix use-after-free after changing collect_md xfrm interfacecollect_md property on xfrm interfaces can only be set on device creation,thus xfrmi_changelink() should fail when called on such interfaces.The check to enforce this was done only in the case where the xi wasreturned from xfrmi_locate() which doesn't look for the collect_mdinterface, and thus the validation was never reached.Calling changelink would thus errornously place the special interface xiin the xfrmi_net->xfrmi hash, but since it also exists in thexfrmi_net->collect_md_xfrmi pointer it would lead to a double free whenthe net namespace was taken down [1].Change the check to use the xi from netdev_priv which is available earlierin the function to prevent changes in xfrm collect_md interfaces.[1] resulting oops:[ 8.516540] kernel BUG at net/core/dev.c:12029![ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary)[ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 8.516569] Workqueue: netns cleanup_net[ 8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0[ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24[ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206[ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60[ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122[ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100[ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00[ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00[ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000[ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0[ 8.516625] PKRU: 55555554[ 8.516627] Call Trace:[ 8.516632] [ 8.516635] ? rtnl_is_locked+0x15/0x20[ 8.516641] ? unregister_netdevice_queue+0x29/0xf0[ 8.516650] ops_undo_list+0x1f2/0x220[ 8.516659] cleanup_net+0x1ad/0x2e0[ 8.516664] process_one_work+0x160/0x380[ 8.516673] worker_thread+0x2aa/0x3c0[ 8.516679] ? __pfx_worker_thread+0x10/0x10[ 8.516686] kthread+0xfb/0x200[ 8.516690] ? __pfx_kthread+0x10/0x10[ 8.516693] ? __pfx_kthread+0x10/0x10[ 8.516697] ret_from_fork+0x82/0xf0[ 8.516705] ? __pfx_kthread+0x10/0x10[ 8.516709] ret_from_fork_asm+0x1a/0x30[ 8.516718]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent infinite loop in rt6_nlmsg_size()While testing prior patch, I was able to triggeran infinite loop in rt6_nlmsg_size() in the following place:list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len);}This is because fib6_del_route() and fib6_add_rt2node()uses list_del_rcu(), which can confuse rcu readers,because they might no longer see the head of the list.Restart the loop if f6i->fib6_nsiblings is zero.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix a race in packet_set_ring() and packet_notifier()When packet_set_ring() releases po->bind_lock, another thread canrun packet_notifier() and process an NETDEV_UP event.This race and the fix are both similar to that of commit 15fe076edea7("net/packet: fix a race in packet_bind() and packet_notifier()").There too the packet_notifier NETDEV_UP event managed to run while apo->bind_lock critical section had to be temporarily released. Andthe fix was similarly to temporarily set po->num to zero to keepthe socket unhooked until the lock is retaken.The po->bind_lock in packet_set_ring and packet_notifier precede theintroduction of git history.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Do not allow binding to VMADDR_PORT_ANYIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This cancause a use-after-free when a connection is made to the bound socket.The socket returned by accept() also has port VMADDR_PORT_ANY but is noton the list of unbound sockets. Binding it will result in an extrarefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keepthe binding until socket destruction).Modify the check in __vsock_bind_connectible() to also prevent bindingto VMADDR_PORT_ANY.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject TDLS operations when station is not associatedsyzbot triggered a WARN in ieee80211_tdls_oper() by sendingNL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,before association completed and without prior TDLS setup.This left internal state like sdata->u.mgd.tdls_peer uninitialized,leading to a WARN_ON() in code paths that assumed it was valid.Reject the operation early if not in station mode or not associated.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix a null pointer dereference in ice_copy_and_init_pkg()Add check for the return value of devm_kmemdup()to prevent potential null pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix vmalloc out-of-bounds write in fast_imageblitThis issue triggers when a userspace program does an ioctlFBIOPUT_CON2FBMAP by passing console number and frame buffer number.Ideally this maps console to frame buffer and updates the screen ifconsole is visible.As part of mapping it has to do resize of console according to framebuffer info. if this resize fails and returns from vc_do_resize() andcontinues further. At this point console and new frame buffer are mappedand sets display vars. Despite failure still it continue to proceedupdating the screen at later stages where vc_data is related to previousframe buffer and frame buffer info and display vars are mapped to newframe buffer and eventully leading to out-of-bounds write infast_imageblit(). This bheviour is excepted only when fg_console isequal to requested console which is a visible console and updates screenwith invalid struct references in fbcon_putcs().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: upper bound check of tree index in dbAllocAGWhen computing the tree index in dbAllocAG, we never check if we areout of bounds realative to the size of the stree.This could happen in a scenario where the filesystem metadata arecorrupted.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Regular file corruption checkThe reproducer builds a corrupted file on disk with a negative i_size value.Add a check when opening this file to avoid subsequent operation failures.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: fix handling of zero-length records on the rx_listEach recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA recordIf the next record has different type than what has already beenprocessed we break out of the main processing loop. If the recordhas already been decrypted (which may be the case for TLS 1.3 wherewe don't know type until decryption) we queue the pending recordto the rx_list. Next recvmsg() will pick it up from there.Queuing the skb to rx_list after zero-copy decrypt is not possible,since in that case we decrypted directly to the user space buffer,and we don't have an skb to queue (darg.skb points to the ciphertextskb for access to metadata like length).Only data records are allowed zero-copy, and we break the processingloop after each non-data record. So we should never zero-copy andthen find out that the record type has changed. The corner casewe missed is when the initial record comes from rx_list, and it'szero length.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()The function divides number of online CPUs by num_core_siblings, andlater checks the divider by zero. This implies a possibility to getand divide-by-zero runtime error. Fix it by moving the check prior todivision. This also helps to save one indentation level.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: truncate good inode pages when hard link is 0The fileset value of the inode copy from the disk by the reproducer isAGGR_RESERVED_I. When executing evict, its hard link number is 0, so itsinode pages are not truncated. This causes the bugon to be triggered whenexecuting clear_inode() because nrpages is greater than 0.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Correct tid cleanup when tid setup failsCurrently, if any error occurs during ath12k_dp_rx_peer_tid_setup(),the tid value is already incremented, even though the correspondingTID is not actually allocated. Proceed toath12k_dp_rx_peer_tid_delete() starting from unallocated tid,which might leads to freeing unallocated TID and cause potentialcrash or out-of-bounds access.Hence, fix by correctly decrementing tid before cleanup to match onlythe successfully allocated TIDs.Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(),as decrementing the tid before cleanup in loop will take care of this.Compile tested only.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Decrement TID on RX peer frag setup error handlingCurrently, TID is not decremented before peer cleanup, during errorhandling path of ath12k_dp_rx_peer_frag_setup(). This could lead toout-of-bounds access in peer->rx_tid[].Hence, add a decrement operation for TID, before peer cleanup toensures proper cleanup and prevents out-of-bounds access issues whenthe RX peer frag setup fails.Found during code review. Compile tested only.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: convert 'use' field to refcount_tThe 'use' field in struct rose_neigh is used as a reference counter butlacks atomicity. This can lead to race conditions where a rose_neighstructure is freed while still being referenced by other code paths.For example, when rose_neigh->use becomes zero during an ioctl operationvia rose_rt_ioctl(), the structure may be removed while its timer isstill active, potentially causing use-after-free issues.This patch changes the type of 'use' from unsigned short to refcount_t andupdates all code paths to use rose_neigh_hold() and rose_neigh_put() whichoperate reference counts atomically.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add validation for ring_len paramThe `ring_len` parameter provided by the virtual function (VF)is assigned directly to the hardware memory context (HMC) withoutany validation.To address this, introduce an upper boundary check for both Tx and Rxqueue lengths. The maximum number of descriptors supported by thehardware is 8k-32.Additionally, enforce alignment constraints: Tx rings must be a multipleof 8, and Rx rings must be a multiple of 32.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix possible UAFsThis attemps to fix possible UAFs caused by struct mgmt_pending beingfreed while still being processed like in the following trace, in orderto fix mgmt_pending_valid is introduce and use to check if themgmt_pending hasn't been removed from the pending list, on the completecallbacks it is used to check and in addtion remove the cmd from the listwhile holding mgmt_pending_lock to avoid TOCTOU problems since if the cmdis left on the list it can still be accessed and freed.BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci0 hci_cmd_sync_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 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 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:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: Defer ip_vs_ftp unregister during netns cleanupOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftpbefore connections with valid cp->app pointers are flushed, leading to ause-after-free.Fix this by introducing a global `exiting_module` flag, set to true inip_vs_ftp_exit() before unregistering the pernet subsystem. In__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netnscleanup (when exiting_module is false) and defer it to__ip_vs_cleanup_batch(), which unregisters all apps after all connectionsare flushed. If called during module exit, unregister ip_vs_ftpimmediately.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit's also checked for decryption and in-place encryption.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Harden userspace-supplied xdp_desc validationTurned out certain clearly invalid values passed in xdp_desc fromuserspace can pass xp_{,un}aligned_validate_desc() and then leadto UBs or just invalid frames to be queued for xmit.desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_lencan cause positive integer overflow and wraparound, the same way lowenough desc->addr with a non-zero pool->tx_metadata_len can causenegative integer overflow. Both scenarios can then pass thevalidation successfully.This doesn't happen with valid XSk applications, but can be usedto perform attacks.Always promote desc->len to ``u64`` first to exclude positiveoverflows of it. Use explicit check_{add,sub}_overflow() whenvalidating desc->addr (which is ``u64`` already).bloat-o-meter reports a little growth of the code size:add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)Function old new deltaxskq_cons_peek_desc 299 330 +31xsk_tx_peek_release_desc_batch 973 1002 +29xsk_generic_xmit 3148 3132 -16but hopefully this doesn't hurt the performance much.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: wait for pending async decryptions if tls_strp_msg_hold failsAsync decryption calls tls_strp_msg_hold to create a clone of theinput skb to hold references to the memory it uses. If we fail toallocate that clone, proceeding with async decryption can lead tovarious issues (UAF on the skb, writing into userspace memory afterthe recv() call has returned).In this case, wait for all pending decryption requests.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().syzbot reported the splat below in tcp_conn_request(). [0]If a listener is close()d while a TFO socket is being processed intcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->skand calls inet_child_forget(), which calls tcp_disconnect() for theTFO socket.After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),where reqsk_put() is called due to !reqsk->sk.Then, reqsk_fastopen_remove() in tcp_conn_request() decrements thelast req->rsk_refcnt and frees reqsk, and __reqsk_free() at thedrop_and_free label causes the refcount underflow for the listenerand double-free of the reqsk.Let's remove reqsk_fastopen_remove() in tcp_conn_request().Note that other callers make sure tp->fastopen_rsk is not NULL.[0]:refcount_t: underflow; use-after-free.WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)Modules linked in:CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0Call Trace: tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]There are multiple issues related to the handling and accessing of guestmemory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- xen-libs < 4.18.5_08-150600.3.34.2 (version in image is 4.18.5_04-150600.3.28.1).
-
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.6 (version in image is 15.6-150600.37.2).
- libsodium23 > 0-0 (version in image is 1.0.18-150000.4.8.1).
-
Description: A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.
Packages affected:
- sle-module-desktop-applications-release == 15.6 (version in image is 15.6-150600.37.2).
- openssh > 0-0 (version in image is 9.6p1-150600.6.29.2).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]Some Viridian hypercalls can specify a mask of vCPU IDs as an input, inone of three formats. Xen has boundary checking bugs with all threeformats, which can cause out-of-bounds reads and writes while processingthe inputs. * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format. * CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- xen-libs < 4.18.5_08-150600.3.34.2 (version in image is 4.18.5_04-150600.3.28.1).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]Some Viridian hypercalls can specify a mask of vCPU IDs as an input, inone of three formats. Xen has boundary checking bugs with all threeformats, which can cause out-of-bounds reads and writes while processingthe inputs. * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format. * CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- xen-libs < 4.18.5_08-150600.3.34.2 (version in image is 4.18.5_04-150600.3.28.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.1.3).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.1.3).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.1.3).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.1.3).
-
Description: OpenLDAP Lightning Memory-Mapped Database (LMDB) versions up to and including 0.9.14, prior to commit 8e1fda8, contain a heap buffer underflow in the readline() function of mdb_load. When processing malformed input containing an embedded NUL byte, an unsigned offset calculation can underflow and cause an out-of-bounds read of one byte before the allocated heap buffer. This can cause mdb_load to crash, leading to a limited denial-of-service condition.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libldap-2_4-2 > 0-0 (version in image is 2.4.46-150600.23.21).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iputDuring unmount process of nilfs2, nothing holds nilfs_root structure afternilfs2 detaches its writer in nilfs_detach_log_writer(). Previously,nilfs_evict_inode() could cause use-after-free read for nilfs_root ifinodes are left in "garbage_list" and released by nilfs_dispose_list atthe end of nilfs_detach_log_writer(), and this bug was fixed by commit9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root innilfs_evict_inode()").However, it turned out that there is another possibility of UAF in thecall path where mark_inode_dirty_sync() is called from iput():nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block() --> causes UAF of nilfs_root structThis can happen after commit 0ae45f63d4ef ("vfs: add support for alazytime mount option"), which changed iput() to callmark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIMEflag and i_nlink is non-zero.This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirtydata after degenerating to read-only") when using the syzbot reproducer,but the issue has potentially existed before.Fix this issue by adding a "purging flag" to the nilfs structure, settingthat flag while disposing the "garbage_list" and checking it in__nilfs_mark_inode_dirty().Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_rootin nilfs_evict_inode()"), this patch does not rely on ns_writer todetermine whether to skip operations, so as not to break recovery onmount. The nilfs_salvage_orphan_logs routine dirties the buffer ofsalvaged data before attaching the log writer, so changing__nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULLwill cause recovery write to fail. The purpose of using the cleanup-onlyflag is to allow for narrowing of such conditions.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dp: Free resources after unregistering themThe DP component's unbind operation walks through the submodules tounregister and clean things up. But if the unbind happens because the DPcontroller itself is being removed, all the memory for those submoduleshas just been freed.Change the order of these operations to avoid the many use-after-freethat otherwise happens in this code path.Patchwork: https://patchwork.freedesktop.org/patch/542166/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lwt: Fix return values of BPF xmit opsBPF encap ops can return different types of positive values, such likeNET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from functionskb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such returnvalues would be treated implicitly as LWTUNNEL_XMIT_CONTINUE inip(6)_finish_output2. When this happens, skbs that have been freed wouldcontinue to the neighbor subsystem, causing use-after-free bug andkernel crashes.To fix the incorrect behavior, skb_do_redirect return values can besimply discarded, the same as tc-egress behavior. On the other hand,bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTUinformation. Thus convert its return values to avoid the conflict withLWTUNNEL_XMIT_CONTINUE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-mmio: don't break lifecycle of vm_devvm_dev has a separate lifecycle because it has a 'struct device'embedded. Thus, having a release callback for it is correct.Allocating the vm_dev struct with devres totally breaks this protection,though. Instead of waiting for the vm_dev release callback, the memoryis freed when the platform_device is removed. Resulting in ause-after-free when finally the callback is to be called.To easily see the problem, compile the kernel withCONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.The fix is easy, don't use devres in this case.Found during my research about object lifetime problems.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: Avoid nf_ct_helper_hash uses after freeIf nf_conntrack_init_start() fails (for example due to aregister_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()clean-up path frees the nf_ct_helper_hash map.When built with NF_CONNTRACK=y, further netfilter modules (e.g:netfilter_conntrack_ftp) can still be loaded and callnf_conntrack_helpers_register(), independently of whether nf_conntrackinitialized correctly. This accesses the nf_ct_helper_hash danglingpointer and causes a uaf, possibly leading to random memory corruption.This patch guards nf_conntrack_helper_register() from accessing a freedor uninitialized nf_ct_helper_hash pointer and fixes possibleuses-after-free when loading a conntrack module.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: 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.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in fill_frame_info()Syzbot reports the following uninit-value access problem.=====================================================BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82It is because VLAN not yet supported in hsr driver. Return errorwhen protocol is ETH_P_8021Q in fill_frame_info() now to fix it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmountsyzbot found an invalid-free in diUnmount:BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674Free of addr ffff88806f410000 by task syz-executor131/3632 CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super.c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1186 task_work_run+0x243/0x300 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x664/0x2070 kernel/exit.c:820 do_group_exit+0x1fd/0x2b0 kernel/exit.c:950 __do_sys_exit_group kernel/exit.c:961 [inline] __se_sys_exit_group kernel/exit.c:959 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd[...]JFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount.If jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount().JFS_IP(ipimap)->i_imap will be freed once again.Fix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libtasn1 > 0-0 (version in image is 4.13-150000.4.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:genirq/irq_sim: Initialize work context pointers properlyInitialize `ops` member's pointers properly by using kzalloc() instead ofkmalloc() when allocating the simulation work context. Otherwise thepointers contain random content leading to invalid dereferencing.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Revert to requiring CAP_SYS_ADMIN for uprobesJann reports that uprobes can be used destructively when used in themiddle of an instruction. The kernel only verifies there is a validinstruction at the requested offset, but due to variable instructionlength cannot determine if this is an instruction as seen by theintended execution stream.Additionally, Mark Rutland notes that on architectures that mix datain the text segment (like arm64), a similar things can be done if thedata word is 'mistaken' for an instruction.As such, require CAP_SYS_ADMIN for uprobes.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Harden s32ton() against conversion to 0 bitsTesting by the syzbot fuzzer showed that the HID core gets ashift-out-of-bounds exception when it tries to convert a 32-bitquantity to a 0-bit quantity. Ideally this should never occur, butthere are buggy devices and some might have a report field with sizeset to zero; we shouldn't reject the report or the device just becauseof that.Instead, harden the s32ton() routine so that it returns a reasonableresult instead of crashing when it is called with the number of bitsset to 0 -- the same as what snto32() does.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pptp: ensure minimal skb length in pptp_xmit()Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb dataon ppp_sync_txmung") fixed ppp_sync_txmunge()We need a similar fix in pptp_xmit(), otherwise we mightread uninit data as reported by syzbot.BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Kill URBs before clearing tx status queueIn rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearingb_tx_status.queue. This change prevents callbacks from using already freedskb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.alCheck pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF inproc_get_inode()"). Followed by AI Viro's suggestion, fix it in samemanner.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: avoid buffer overflow in WID string configurationFix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)This patch introduces size check before accessing the memory buffer.The checks are base on the WID type of received data from the firmware.For WID string configuration, the size limit is determined by individualelement size in 'struct wilc_cfg_str_vals' that is maintained in 'len' fieldof 'struct wilc_cfg_str'.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: xfrm_alloc_spi shouldn't use 0 as SPIx->id.spi == 0 means "no SPI assigned", but since commit94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create statesand add them to the byspi list with this value.__xfrm_state_delete doesn't remove those states from the byspi list,since they shouldn't be there, and this shows up as a UAF the nexttime we go through the byspi list.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: The CNI portmap plugin allows containers to emulate opening a host port, forwarding that traffic to the container. Versions 1.6.0 through 1.8.0 inadvertently forward all traffic with the same destination port as the host port when the portmap plugin is configured with the nftables backend, thus ignoring the destination IP. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node. Containers that request HostPort forwarding can intercept all traffic destined for that port. This requires that the portmap plugin be explicitly configured to use the nftables backend. This issue is fixed in version 1.9.0. To workaround, configure the portmap plugin to use the iptables backend. It does not have this vulnerability.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]There are multiple issues related to the handling and accessing of guestmemory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- xen-libs < 4.18.5_08-150600.3.34.2 (version in image is 4.18.5_04-150600.3.28.1).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]There are multiple issues related to the handling and accessing of guestmemory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- xen-libs < 4.18.5_08-150600.3.34.2 (version in image is 4.18.5_04-150600.3.28.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firewire: net: fix use after free in fwnet_finish_incoming_packet()The netif_rx() function frees the skb so we can't dereference it tosave the skb->len.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix incomplete state save in rxe_requesterIf a send packet is dropped by the IP layer in rxe_requester()the call to rxe_xmit_packet() can fail with err == -EAGAIN.To recover, the state of the wqe is restored to the state beforethe packet was sent so it can be resent. However, the routinesthat save and restore the state miss a significnt part of thevariable state in the wqe, the dma struct which is used to processthrough the sge table. And, the state is not saved before the packetis built which modifies the dma struct.Under heavy stress testing with many QPs on a fast node sendinglarge messages to a slow node dropped packets are observed andthe resent packets are corrupted because the dma struct was notrestored. This patch fixes this behavior and allows the test casesto succeed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: reject auth/assoc to AP with our addressIf the AP uses our own address as its MLD address or BSSID, thenclearly something's wrong. Reject such connections so we don'ttry and fail later.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: qmi_encdec: Restrict string length in decodeThe QMI TLV value for strings in a lot of qmi element info structuresaccount for null terminated strings with MAX_LEN + 1. If a string isactually MAX_LEN + 1 length, this will cause an out of bounds accesswhen the NULL character is appended in decoding.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- curl < 8.14.1-150600.4.31.1 (version in image is 8.14.1-150600.4.28.1).
-
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-development-tools-release == 15.6 (version in image is 15.6-150600.37.2).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- glib2-tools > 0-0 (version in image is 2.78.6-150600.4.16.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix the dead loop of MPLS parseThe unexpected MPLS packet may not end with the bottom label stack.When there are many stacks, The label count value has wrapped around.A dead loop occurs, soft lockup/CPU stuck finally.stack backtrace:UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26index -1 is out of range for type '__be32 [3]'CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-UbuntuHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: prevent A-MSDU attacks in mesh networksThis patch is a mitigation to prevent the A-MSDU spoofing vulnerabilityfor mesh networks. The initial update to the IEEE 802.11 standard, inresponse to the FragAttacks, missed this case (CVE-2025-27558). It canbe considered a variant of CVE-2020-24588 but for mesh networks.This patch tries to detect if a standard MSDU was turned into an A-MSDUby an adversary. This is done by parsing a received A-MSDU as a standardMSDU, calculating the length of the Mesh Control header, and seeing ifthe 6 bytes after this header equal the start of an rfc1042 header. Ifequal, this is a strong indication of an ongoing attack attempt.This defense was tested with mac80211_hwsim against a mesh network thatuses an empty Mesh Address Extension field, i.e., when four addressesare used, and when using a 12-byte Mesh Address Extension field, i.e.,when six addresses are used. Functionality of normal MSDUs and A-MSDUswas also tested, and confirmed working, when using both an empty and12-byte Mesh Address Extension field.It was also tested with mac80211_hwsim that A-MSDU attacks in non-meshnetworks keep being detected and prevented.Note that the vulnerability being patched, and the defense beingimplemented, was also discussed in the following paper and in thefollowing IEEE 802.11 presentation:https://papers.mathyvanhoef.com/wisec2025.pdfhttps://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix race with concurrent opens in rename(2)Besides sending the rename request to the server, the rename processalso involves closing any deferred close, waiting for outstanding I/Oto complete as well as marking all existing open handles as deleted toprevent them from deferring closes, which increases the race windowfor potential concurrent opens on the target file.Fix this by unhashing the dentry in advance to prevent any concurrentopens on the target.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmscape: Add conditional IBPB mitigationVMSCAPE is a vulnerability that exploits insufficient branch predictorisolation between a guest and a userspace hypervisor (like QEMU). Existingmitigations already protect kernel/KVM from a malicious guest. Userspacecan additionally be protected by flushing the branch predictors after aVMexit.Since it is the userspace that consumes the poisoned branch predictors,conditionally issue an IBPB after a VMexit and before returning touserspace. Workloads that frequently switch between hypervisor anduserspace will incur the most overhead from the new IBPB.This new IBPB is not integrated with the existing IBPB sites. Forinstance, a task can use the existing speculation control prctl() toget an IBPB at context switch time. With this implementation, theIBPB is doubled up: one at context switch and another before runninguserspace.The intent is to integrate and optimize these cases post-embargo.[ dhansen: elaborate on suboptimal IBPB solution ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: When passing through PCI devices, the detach logic in libxl won't removeaccess permissions to any 64bit memory BARs the device might have. As aresult a domain can still have access any 64bit memory BAR when suchdevice is no longer assigned to the domain.For PV domains the permission leak allows the domain itself to map the memoryin the page-tables. For HVM it would require a compromised device model orstubdomain to map the leaked memory into the HVM domain p2m.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- xen-libs < 4.18.5_08-150600.3.34.2 (version in image is 4.18.5_04-150600.3.28.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: remove write-after-free of client_idA use-after-free error popped up in stress testing:[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core][Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):[Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core][Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core][Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70[Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180[Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80[Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0[Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80The actual device uninit usually happens on a separate threadscheduled after this code runs, but there is no guarantee of orderof thread execution, so this could be a problem. There's noactual need to clear the client_id at this point, so simplyremove the offending code.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: Avoid updating block size under exclusive ownerSyzbot came up with a reproducer where a loop device block size ischanged underneath a mounted filesystem. This causes a mismatch betweenthe block device block size and the block size stored in the superblockcausing confusion in various places such as fs/buffer.c. The particularissue triggered by syzbot was a warning in __getblk_slow() due torequested buffer size not matching block device block size.Fix the problem by getting exclusive hold of the loop device to changeits block size. This fails if somebody (such as filesystem) has alreadyan exclusive ownership of the block device and thus prevents modifyingthe loop device under some exclusive owner which doesn't expect it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix race between quota disable and quota rescan ioctlThere's a race between a task disabling quotas and another running therescan ioctl that can result in a use-after-free of qgroup records fromthe fs_info->qgroup_tree rbtree.This happens as follows:1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().Also at btrfs_qgroup_rescan() don't start the rescan worker if quotaswere already disabled.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cnic: Fix use-after-free bugs in cnic_delete_taskThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),which does not guarantee that the delayed work item 'delete_task' hasfully completed if it was already running. Additionally, the delayed workitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() onlyblocks and waits for work items that were already queued to theworkqueue prior to its invocation. Any work items submitted afterflush_workqueue() is called are not included in the set of tasks that theflush operation awaits. This means that after the cyclic work items havefinished executing, a delayed work item may still exist in the workqueue.This leads to use-after-free scenarios where the cnic_dev is deallocatedby cnic_free_dev(), while delete_task remains active and attempt todereference cnic_dev in cnic_delete_task().A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //useReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the cyclic delayed work item is properly canceled and that anyongoing execution of the work item completes before the cnic_dev isdeallocated. Furthermore, since cancel_delayed_work_sync() uses__flush_work(work, true) to synchronously wait for any currentlyexecuting instance of the work item to finish, the flush_workqueue()becomes redundant and should be removed.This bug was identified through static analysis. To reproduce the issueand validate the fix, I simulated the cnic PCI device in QEMU andintroduced intentional delays - such as inserting calls to ssleep()within the cnic_delete_task() function - to increase the likelihoodof triggering the bug.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver just ignores and leaves as is, which may lead tounepxected results like OOB access.This patch adds the sanity check and corrects the input mapping to thecertain default value if an invalid value is passed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver only shows an error message but leaves as is.This may lead to unepxected results like OOB access.This patch corrects the input mapping to the certain default value ifan invalid value is passed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Wait for io return on terminate rportSystem crash due to use after free.Current code allows terminate_rport_io to exit before makingsure all IOs has returned. For FCP-2 device, IO's can hangon in HW because driver has not tear down the session in FW atfirst sign of cable pull. When dev_loss_tmo timer pops,terminate_rport_io is called and upper layer is about tofree various resources. Terminate_rport_io trigger qla to dothe final cleanup, but the cleanup might not be fast enough where itleave qla still holding on to the same resource.Wait for IO's to return to upper layer before resources are freed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLevSyzkaller reported the following issue:UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6index -84 is out of range for type 's8[341]' (aka 'signed char[341]')CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #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+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965 dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809 dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350 dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874 dtSplitUp fs/jfs/jfs_dtree.c:974 [inline] dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863 jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137 lookup_open fs/namei.c:3492 [inline] open_last_lookups fs/namei.c:3560 [inline] path_openat+0x13df/0x3170 fs/namei.c:3788 do_filp_open+0x234/0x490 fs/namei.c:3818 do_sys_openat2+0x13f/0x500 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_openat fs/open.c:1388 [inline] __se_sys_openat fs/open.c:1383 [inline] __x64_sys_openat+0x247/0x290 fs/open.c:1383 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/0xcdRIP: 0033:0x7f1f4e33f7e9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: 0000000000000101RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f4e33f7e9RDX: 000000000000275a RSI: 0000000020000040 RDI: 00000000ffffff9cRBP: 00007f1f4e2ff080 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1f4e2ff110R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 The bug occurs when the dbAllocDmapLev()function attempts to accessdp->tree.stree[leafidx + LEAFIND] while the leafidx value is negative.To rectify this, the patch introduces a safeguard within thedbAllocDmapLev() function. A check has been added to verify if leafidx isnegative. If it is, the function immediately returns an I/O error, preventingany further execution that could potentially cause harm.Tested via syzbot.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- curl > 0-0 (version in image is 8.14.1-150600.4.28.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: fix race condition in unaccepted memory handlingThe page allocator tracks the number of zones that have unaccepted memoryusing static_branch_enc/dec() and uses that static branch in hot paths todetermine if it needs to deal with unaccepted memory.Borislav and Thomas pointed out that the tracking is racy: operations onstatic_branch are not serialized against adding/removing unaccepted pagesto/from the zone.Sanity checks inside static_branch machinery detects it:WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */The effect of this static_branch optimization is only visible onmicrobenchmark.Instead of adding more complexity around it, remove it altogether.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()The hfsplus_readdir() method is capable to crash by callinghfsplus_uni2asc():[ 667.121659][ T9805] ==================================================================[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805[ 667.124578][ T9805][ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 667.124890][ T9805] Call Trace:[ 667.124893][ T9805] [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0[ 667.124911][ T9805] print_report+0xd0/0x660[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10[ 667.124942][ T9805] kasan_report+0xc6/0x100[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0[ 667.125022][ T9805] ? lock_acquire+0x30/0x80[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0[ 667.125044][ T9805] ? putname+0x154/0x1a0[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0[ 667.125069][ T9805] iterate_dir+0x296/0xb20[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0[ 667.125143][ T9805] do_syscall_64+0xc9/0x480[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 667.125207][ T9805] [ 667.125210][ T9805][ 667.145632][ T9805] Allocated by task 9805:[ 667.145991][ T9805] kasan_save_stack+0x20/0x40[ 667.146352][ T9805] kasan_save_track+0x14/0x30[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0[ 667.148174][ T9805] iterate_dir+0x296/0xb20[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0[ 667.148937][ T9805] do_syscall_64+0xc9/0x480[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 667.149809][ T9805][ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)[ 667.1---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()The hfsplus_bnode_read() method can trigger the issue:[ 174.852007][ T9784] ==================================================================[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784[ 174.854059][ T9784][ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 174.854286][ T9784] Call Trace:[ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0[ 174.854305][ T9784] print_report+0xd0/0x660[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854337][ T9784] kasan_report+0xc6/0x100[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10[ 174.854436][ T9784] ? __asan_memset+0x23/0x50[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10[ 174.854525][ T9784] ? down_write+0x148/0x200[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0[ 174.854549][ T9784] do_unlinkat+0x490/0x670[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10[ 174.854565][ T9784] ? __might_fault+0xbc/0x130[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110[ 174.854592][ T9784] do_syscall_64+0xc9/0x480[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 174.854658][ T9784] [ 174.854661][ T9784][ 174.879281][ T9784] Allocated by task 9784:[ 174.879664][ T9784] kasan_save_stack+0x20/0x40[ 174.880082][ T9784] kasan_save_track+0x14/0x30[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: nci: Add parameter validation for packet dataSyzbot reported an uninitialized value bug in nci_init_req, which wasintroduced by commit 5aca7966d2a7 ("Merge tag'perf-tools-fixes-for-v6.17-2025-09-16' ofgit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").This bug arises due to very limited and poor input validationthat was done at nic_valid_size(). This validation onlyvalidates the skb->len (directly reflects size provided at theuserspace interface) with the length provided in the bufferitself (interpreted as NCI_HEADER). This leads to the processingof memory content at the address assuming the correct layoutper what opcode requires there. This leads to the accesses tobuffer of `skb_buff->data` which is not assigned anything yet.Following the same silent drop of packets of invalid sizes at`nic_valid_size()`, add validation of the data in the respectivehandlers and return error values in case of failure. Releasethe skb if error values are returned from handlers in`nci_nft_packet` and effectively do a silent dropPossible TODO: because we silently drop the packets, thecall to `nci_request` will be waiting for completion of requestand will face timeouts. These timeouts can get excessively loggedin the dmesg. A proper handling of them may require to export`nci_request_cancel` (or propagate error handling from thenft packets handlers).
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: udf: fix OOB read in lengthAllocDescs handlingWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes fromon-disk data and must be validated against the block size. Crafted orcorrupted images may set lengthAllocDescs so that the total descriptorlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory andtrigger a KASAN use-after-free read.BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: ISO: Fix possible UAF on iso_conn_freeThis attempt to fix similar issue to sco_conn_free where if theconn->sk is not set to NULL may lead to UAF on iso_conn_free.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loopThe cleanup loop was starting at the wrong array index, causingout-of-bounds access.Start the loop at the correct index for zero-indexed arrays to preventaccessing memory beyond the allocated array bounds.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()In az6007_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach az6007_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Add length check when parsing nlattrsThere are three places that qla4xxx parses nlattrs: - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param()and each of them directly converts the nlattr to specific pointer ofstructure without length checking. This could be dangerous as thoseattributes are not validated and a malformed nlattr (e.g., length 0) couldresult in an OOB read that leaks heap dirty data.Add the nla_len check before accessing the nlattr data and return EINVAL ifthe length check fails.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob writeWhen the oob buffer length is not in multiple of words, the oob writefunction does out-of-bounds read on the oob source buffer at the lastiteration. Fix that by always checking length limit on the oob bufferread and fill with 0xff when reaching the end of the buffer to the oobregisters.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix potential array out of bounds accessAccount for IWL_SEC_WEP_KEY_OFFSET when needed while verifyingkey_len size in iwl_mvm_sec_key_add().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: don't dereference mddev after export_rdev()Except for initial reference, mddev->kobject is referenced byrdev->kobject, and if the last rdev is freed, there is no guarantee thatmddev is still valid. Hence mddev should not be used anymore afterexport_rdev().This problem can be triggered by following test for mdadm at verylow rate: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:general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMPCPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]Call Trace: mddev_unlock+0x1b6/0x310 [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 this problem by don't dereference mddev after export_rdev().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability has been found in GNU Binutils 2.45. This impacts the function bfd_elf_gc_record_vtentry of the file bfd/elflink.c of the component Linker. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier of the patch is 047435dd988a3975d40c6626a8f739a0b2e154bc. To fix this issue, it is recommended to deploy a patch.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was found in GNU Binutils 2.45. Affected is the function elf_link_add_object_symbols of the file bfd/elflink.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. Upgrading to version 2.46 is able to address this issue. The patch is identified as 72efdf166aa0ed72ecc69fc2349af6591a7a19c0. Upgrading the affected component is advised.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was determined in GNU Binutils 2.45. Affected by this vulnerability is the function get_link_hash_entry of the file bfd/elflink.c of the component Linker. This manipulation causes out-of-bounds read. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Upgrading to version 2.46 addresses this issue. Patch name: aeaaa9af6359c8e394ce9cf24911fec4f4d23703. It is advisable to upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.
Packages affected:
- sle-module-server-applications-release == 15.6 (version in image is 15.6-150600.37.2).
- util-linux > 0-0 (version in image is 2.39.3-150600.4.12.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mctp: Don't access ifa_index when missingIn mctp_dump_addrinfo, ifa_index can be used to filter interfaces, butonly when the struct ifaddrmsg is provided. Otherwise it will becomparing to uninitialised memory - reproducible in the syzkaller case fromdhcpd, or busybox "ip addr show".The kernel MCTP implementation has always filtered by ifa_index, soexisting userspace programs expecting to dump MCTP addresses mustalready be passing a valid ifa_index value (either 0 or a real index).BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()syzbot found a potential access to uninit-value in nf_flow_pppoe_proto()Blamed commit forgot the Ethernet header.BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()The "intf" list iterator is an invalid pointer if the correct"intf->intf_num" is not found. Calling atomic_dec(&intf->nr_users) onand invalid pointer will lead to memory corruption.We don't really need to call atomic_dec() if we haven't calledatomic_add_return() so update the if (intf->in_shutdown) path as well.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: aio_iiro_16: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl812: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: common: st_sensors: Fix use of uninitialize device structsThroughout the various probe functions &indio_dev->dev is used before itis initialized. This caused a kernel panic in st_sensors_power_enable()when the call to devm_regulator_bulk_get_enable() fails and then callsdev_err_probe() with the uninitialized device.This seems to only cause a panic with dev_err_probe(), dev_err(),dev_warn() and dev_info() don't seem to cause a panic, but are fixedas well.The issue is reported and traced here: [1]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: libwx: fix the using of Rx buffer DMAThe wx_rx_buffer structure contained two DMA address fields: 'dma' and'page_dma'. However, only 'page_dma' was actually initialized and usedto program the Rx descriptor. But 'dma' was uninitialized and used insome paths.This could lead to undefined behavior, including DMA errors oruse-after-free, if the uninitialized 'dma' was used. Althrough sucherror has not yet occurred, it is worth fixing in the code.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: mqprio: fix stack out-of-bounds write in tc entry parsingTCA_MQPRIO_TC_ENTRY_INDEX is validated usingNLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the valueTC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stackwrite in the fp[] array, which only has room for 16 elements (0-15).Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix double destruction of rsv_qprsv_qp may be double destroyed in error flow, first in free_mr_init(),and then in hns_roce_exit(). Fix it by moving the free_mr_init() callinto hns_roce_v2_init().list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100)WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240...Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in i40e_validate_queue_mapEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_validate_queue_map().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: peak_usb: fix shift-out-of-bounds issueExplicitly uses a 64-bit constant when the number of bits used for itsshifting is 32 (which is the case for PC CAN FD interfaces supported bythis driver).[mkl: update subject, apply manually]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Fix copy_to_iter return value checkThe return value of copy_to_iter can't be negative, check whether thecopied length is equal to the requested length instead of checking fornegative values.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer deference in try_to_register_cardIn try_to_register_card(), the return value of usb_ifnum_to_if() ispassed directly to usb_interface_claimed() without a NULL check, whichwill lead to a NULL pointer dereference when creating an invalidUSB audio device. Fix this by adding a check to ensure the interfacepointer is valid before passing it to usb_interface_claimed().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmodSince commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero whendevice is gone") UBSAN reports: UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17 index 28 is out of range for type 'pm8001_phy [16]'on rmmod when using an expander.For a direct attached device, attached_phy contains the local phy id.For a device behind an expander, attached_phy contains the remote phyid, not the local phy id.I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for adevice behind an expander, attached_phy can be much larger thanpm8001_ha->chip->n_phy (depending on the amount of phys of theexpander).E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of theports has an expander connected. The expander has 31 phys with phy ids0-30.The pm8001_ha->phy array only contains the phys of the HBA. It does notcontain the phys of the expander. Thus, it is wrong to use attached_phyto index the pm8001_ha->phy array for a device behind an expander.Thus, we can only clear phy_attached for devices that are directlyattached.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Check instead of asserting on nested TSC scaling supportCheck for nested TSC scaling support on nested SVM VMRUN instead ofasserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIOhas diverged from KVM's default. Userspace can trigger the WARN at willby writing the MSR and then updating guest CPUID to hide the feature(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hackingKVM's state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd] Call Trace: enter_svm_guest_mode+0x114/0x560 [kvm_amd] nested_svm_vmrun+0x260/0x330 [kvm_amd] vmrun_interception+0x29/0x30 [kvm_amd] svm_invoke_exit_handler+0x35/0x100 [kvm_amd] svm_handle_exit+0xe7/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x45ca1bNote, the nested #VMEXIT path has the same flaw, but needs a differentfix and will be handled separately.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: fix potential buffer overflow in do_register_framebuffer()The current implementation may lead to buffer overflow when:1. Unregistration creates NULL gaps in registered_fb[]2. All array slots become occupied despite num_registered_fb < FB_MAX3. The registration loop exceeds array boundsAdd boundary check to prevent registered_fb[FB_MAX] access.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/buffer: fix use-after-free when call bh_read() helperThere's issue as follows:BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer wait_on_buffer(bh);--> return will return to caller put_bh --> trigger stack-out-of-boundsIn the mpage_read_folio() function, the stack variable 'map_bh' ispassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks andwait_on_buffer() returns to continue processing, the stack variableis likely to be reclaimed. Consequently, during the end_buffer_read_sync()process, calling put_bh() may result in stack overrun.If the bh is not allocated on the stack, it belongs to a folio. Freeinga buffer head which belongs to a folio is done by drop_buffers() whichwill fail to free buffers which are still locked. So it is safe to callput_bh() before __end_buffer_read_notouch().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: REXML is an XML toolkit for Ruby. The REXML gem before 3.3.9 has a ReDoS vulnerability when it parses an XML that has many digits between and x...; in a hex numeric character reference (...;). This does not happen with Ruby 3.2 or later. Ruby 3.1 is the only affected maintained Ruby. The REXML gem 3.3.9 or later include the patch to fix the vulnerability.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.1).
-
Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- krb5 < 1.20.1-150600.11.14.1 (version in image is 1.20.1-150600.11.11.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Duplicate SPI HandlingThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPINetlink message, which triggers the kernel function xfrm_alloc_spi().This function is expected to ensure uniqueness of the Security ParameterIndex (SPI) for inbound Security Associations (SAs). However, it canreturn success even when the requested SPI is already in use, leadingto duplicate SPIs assigned to multiple inbound SAs, differentiatedonly by their destination addresses.This behavior causes inconsistencies during SPI lookups for inbound packets.Since the lookup may return an arbitrary SA among those with the same SPI,packet processing can fail, resulting in packet drops.According to RFC 4301 section 4.4.2 , for inbound processing a unicast SAis uniquely identified by the SPI and optionally protocol.Reproducing the Issue Reliably:To consistently reproduce the problem, restrict the available SPI range incharon.conf : spi_min = 0x10000000 spi_max = 0x10000002This limits the system to only 2 usable SPI values.Next, create more than 2 Child SA. each using unique pair of src/dst address.As soon as the 3rd Child SA is initiated, it will be assigned a duplicateSPI, since the SPI pool is already exhausted.With a narrow SPI range, the issue is consistently reproducible.With a broader/default range, it becomes rare and unpredictable.Current implementation:xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.So if two SAs have the same SPI but different destination addresses, thenthey will:a. Hash into different bucketsb. Be stored in different linked lists (byspi + h)c. Not be seen in the same hlist_for_each_entry_rcu() iteration.As a result, the lookup will result in NULL and kernel allows that Duplicate SPIProposed Change:xfrm_state_lookup_spi_proto() does a truly global search - across all states,regardless of hash bucket and matches SPI and proto.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/MCE: Always save CS register on AMD Zen IF Poison errorsThe Instruction Fetch (IF) units on current AMD Zen-based systems do notguarantee a synchronous #MC is delivered for poison consumption errors.Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, themicroarchitecture does guarantee that the exception is delivered withinthe same context. In other words, the exact rIP is not known, but thecontext is known to not have changed.There is no architecturally-defined method to determine this behavior.The Code Segment (CS) register is always valid on such IF unit poisonerrors regardless of the value of MCG_STATUS[EIPV|RIPV].Add a quirk to save the CS register for poison consumption from the IFunit banks.This is needed to properly determine the context of the error.Otherwise, the severity grading function will assume the context isIN_KERNEL due to the m->cs value being 0 (the initialized value). Thisleads to unnecessary kernel panics on data poison errors due to thekernel believing the poison consumption occurred in kernel context.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix a NULL pointer dereference in ath12k_mac_op_hw_scan()In ath12k_mac_op_hw_scan(), the return value of kzalloc() is directlyused in memcpy(), which may lead to a NULL pointer dereference onfailure of kzalloc().Fix this bug by adding a check of arg.extraie.ptr.Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_conn_close().syzbot reported a null-ptr-deref in tipc_conn_close() during netnsdismantle. [0]tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and callstipc_conn_close() for each tipc_conn.The problem is that tipc_conn_close() is called after releasing theIDR lock.At the same time, there might be tipc_conn_recv_work() running and itcould call tipc_conn_close() for the same tipc_conn and release itslast ->kref.Once we release the IDR lock in tipc_topsrv_stop(), there is noguarantee that the tipc_conn is alive.Let's hold the ref before releasing the lock and put the ref aftertipc_conn_close() in tipc_topsrv_stop().[0]:BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00)The buggy address belongs to the page:page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0flags: 0xfff00000000100(slab)raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: plug races between subflow fail and subflow creationWe have races similar to the one addressed by the previous patch betweensubflow failing and additional subflow creation. They are just harder totrigger.The solution is similar. Use a separate flag to track the condition'socket state prevent any additional subflow creation' protected by thefallback lock.The socket fallback makes such flag true, and also receiving or sendingan MP_FAIL option.The field 'allow_infinite_fallback' is now always touched under therelevant lock, we can drop the ONCE annotation on write.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject: don't leak dst refcount for loopback packetsrecent patches to add a WARN() when replacing skb dst entry found anold bug:WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234[..]Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] ..This is because blamed commit forgot about loopback packets.Such packets already have a dst_entry attached, even at PRE_ROUTING stage.Instead of checking hook just check if the skb already has a routeattached to it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent NULL pointer dereference in UTF16 conversionThere can be a NULL pointer dereference bug here. NULL is passed to__cifs_sfu_make_node without checks, which passes it unchecked tocifs_strndup_to_utf16, which in turn passes it tocifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 andreturns NULL early to prevent dereferencing NULL pointer.Found by Linux Verification Center (linuxtesting.org) with SVACE
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: cadence-quadspi: Implement refcount to handle unbind during busydriver support indirect read and indirect write operation withassumption no force device removal(unbind) operation. Howeverforce device removal(removal) is still available to root superuser.Unbinding driver during operation causes kernel crash. This changesensure driver able to handle such operation for indirect read andindirect write by implementing refcount to track attached devicesto the controller and gracefully wait and until attached devicesremove operation completed before proceed with removal operation.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix potential double free in drm_sched_job_add_resv_dependenciesWhen adding dependencies with drm_sched_job_add_dependency(), thatfunction consumes the fence reference both on success and failure, so inthe latter case the dma_fence_put() on the error path (xarray failed toexpand) is a double free.Interestingly this bug appears to have been present ever sincecommit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the codeback then looked like this:drm_sched_job_add_implicit_dependencies():... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]);Which means for the failing 'i' the dma_fence_put was already a doublefree. Possibly there were no users at that time, or the test cases wereinsufficient to hit it.The bug was then only noticed and fixed aftercommit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")landed, with its fixup ofcommit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").At that point it was a slightly different flavour of a double free, whichcommit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")noticed and attempted to fix.But it only moved the double free from happening inside thedrm_sched_job_add_dependency(), when releasing the reference not yetobtained, to the caller, when releasing the reference already released bythe former in the failure case.As such it is not easy to identify the right target for the fixes tag solets keep it simple and just continue the chain.While fixing we also improve the comment and explain the reason for takingthe reference and not dropping it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject negative offsets for ALU opsWhen verifying BPF programs, the check_alu_op() function validatesinstructions with ALU operations. The 'offset' field in theseinstructions is a signed 16-bit integer.The existing check 'insn->off > 1' was intended to ensure the offset iseither 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' issigned, this check incorrectly accepts all negative values (e.g., -1).This commit tightens the validation by changing the condition to'(insn->off != 0 && insn->off != 1)'. This ensures that any valueother than the explicitly permitted 0 and 1 is rejected, hardening theverifier against malformed BPF programs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ax25: properly unshare skbs in ax25_kiss_rcv()Bernard Pidoux reported a regression apparently caused by commitc353e8983e0d ("net: introduce per netns packet chains").skb->dev becomes NULL and we crash in __netif_receive_skb_core().Before above commit, different kind of bugs or corruptions could happenwithout a major crash.But the root cause is that ax25_kiss_rcv() can queue/mangle input skbwithout checking if this skb is shared or not.Many thanks to Bernard Pidoux for his help, diagnosis and tests.We had a similar issue years ago fixed with commit 7aaed57c5c28("phonet: properly unshare skbs in phonet_rcv()").
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: make sure skb->len != 0 when redirecting to a tunneling devicesyzkaller managed to trigger another case where skb->len == 0when we enter __dev_queue_xmit:WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6The reproducer doesn't really reproduce outside of syzkallerenvironment, so I'm taking a guess here. It looks like wedo generate correct ETH_HLEN-sized packet, but we redirectthe packet to the tunneling device. Before we do so, we__skb_pull l2 header and arrive again at skb->len == 0.Doesn't seem like we can do anything better than havingan explicit check after __skb_pull?
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A flaw was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix wrong next length validation of ea buffer in smb2_set_ea()There are multiple smb2_ea_info buffers in FILE_FULL_EA_INFORMATION requestfrom client. ksmbd find next smb2_ea_info using ->NextEntryOffset ofcurrent smb2_ea_info. ksmbd need to validate buffer length Beforeaccessing the next ea. ksmbd should check buffer length using buf_len,not next variable. next is the start offset of current ea that got fromprevious ea.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: validate command request sizeIn commit 2b9b8f3b68ed ("ksmbd: validate command payload size"), exceptfor SMB2_OPLOCK_BREAK_HE command, the request size of other commandsis not checked, it's not expected. Fix it by add check for requestsize of other commands.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: add NULL check in xfrm_update_ae_paramsNormally, x->replay_esn and x->preplay_esn should be allocated atxfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence thexfrm_update_ae_params(...) is okay to update them. However, the currentimplementation of xfrm_new_ae(...) allows a malicious user to directlydereference a NULL pointer and crash the kernel like below.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0Oops: 0002 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4RIP: 0010:memcpy_orig+0xad/0x140Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 cRSP: 0018:ffff888008f57658 EFLAGS: 00000202RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x1e8/0x500 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? fixup_exception+0x36/0x460 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? exc_page_fault+0x5e/0xc0 ? asm_exc_page_fault+0x26/0x30 ? xfrm_update_ae_params+0xd1/0x260 ? memcpy_orig+0xad/0x140 ? __pfx__raw_spin_lock_bh+0x10/0x10 xfrm_update_ae_params+0xe7/0x260 xfrm_new_ae+0x298/0x4e0 ? __pfx_xfrm_new_ae+0x10/0x10 ? __pfx_xfrm_new_ae+0x10/0x10 xfrm_user_rcv_msg+0x25a/0x410 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __alloc_skb+0xcf/0x210 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1c/0x70 ? __stack_depot_save+0x39/0x4e0 ? __kasan_slab_free+0x10a/0x190 ? kmem_cache_free+0x9c/0x340 ? netlink_recvmsg+0x23c/0x660 ? sock_recvmsg+0xeb/0xf0 ? __sys_recvfrom+0x13c/0x1f0 ? __x64_sys_recvfrom+0x71/0x90 ? do_syscall_64+0x3f/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc ? copyout+0x3e/0x50 netlink_rcv_skb+0xd6/0x210 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_sock_has_perm+0x10/0x10 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 xfrm_netlink_rcv+0x44/0x50 netlink_unicast+0x36f/0x4c0 ? __pfx_netlink_unicast+0x10/0x10 ? netlink_recvmsg+0x500/0x660 netlink_sendmsg+0x3b7/0x700This Null-ptr-deref bug is assigned CVE-2023-3772. And this commitadds additional NULL check in xfrm_update_ae_params to fix the NPD.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Pointer may be dereferencedKlocwork tool reported pointer 'rport' returned from call to functionfc_bsg_to_rport() may be NULL and will be dereferenced.Add a fix to validate rport before dereferencing.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: prevent soft lockup while flush writesCurrently, there is no limit for raid1/raid10 plugged bio. While flushingwrites, raid1 has cond_resched() while raid10 doesn't, and too manywrites can cause soft lockup.Follow up soft lockup can be triggered easily with writeback test forraid10 with ramdisks:watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]Call Trace: call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0Fix the problem by adding cond_resched() to raid10 like what raid1 did.Note that unlimited plugged bio still need to be optimized, for example,in the case of lots of dirty pages writeback, this will take lots ofmemory and io will spend a long time in plug, hence io latency is bad.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix calltrace warning in amddrm_buddy_finiThe following call trace is observed when removing the amdgpu driver, whichis caused by that BOs allocated for psp are not freed until removing.[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy][61811.450577] Call Trace:[61811.450577] [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu][61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu][61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu][61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu][61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu][61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu][61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm][61811.451466] devm_action_release+0x15/0x20[61811.451469] release_nodes+0x40/0xb0[61811.451471] devres_release_all+0x9b/0xd0[61811.451473] __device_release_driver+0x1bb/0x2a0[61811.451476] driver_detach+0xf3/0x140[61811.451479] bus_remove_driver+0x6c/0xf0[61811.451481] driver_unregister+0x31/0x60[61811.451483] pci_unregister_driver+0x40/0x90[61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]For smu v13_0_2, if the GPU supports xgmi, refer tocommit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,which makes all devices in hive list have hw reset but no resume except thebasic ip blocks, then other ip blocks will not call .hw_fini according toip_block.status.hw.Since psp_free_shared_bufs just includes some software operations, so moveit to psp_sw_fini.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix null pointer dereference in tracing_err_log_open()Fix an issue in function 'tracing_err_log_open'.The function doesn't call 'seq_open' if the file is opened only withwrite permissions, which results in 'file->private_data' being left as null.If we then use 'lseek' on that opened file, 'seq_lseek' dereferences'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic.Writing to this node requires root privileges, therefore this bughas very little security impact.Tracefs node: /sys/kernel/tracing/error_logExample Kernel panic:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038Call trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)---[ end trace 561d1b49c12cf8a5 ]---Kernel panic - not syncing: Oops: Fatal exception
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Removed unneeded of_node_put in felix_parse_ports_nodeRemove unnecessary of_node_put from the continue path to preventchild node from being released twice, which could avoid resourceleak or other unexpected issues.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix possible memory leak if device_add() failsIf device_add() returns error, the name allocated by dev_set_name() needsbe freed. As the comment of device_add() says, put_device() should be usedto decrease the reference count in the error path. So fix this by callingput_device(), then the name can be freed in kobject_cleanp().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernationWhen a Linux VM with an assigned PCI device runs on Hyper-V, if the PCIdevice driver is not loaded yet (i.e. MSI-X/MSI is not enabled on thedevice yet), doing a VM hibernation triggers a panic inhv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), becausepdev->dev.msi.data is still NULL.Avoid the panic by checking if MSI-X/MSI is enabled.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: hi846: fix usage of pm_runtime_get_if_in_use()pm_runtime_get_if_in_use() does not only return nonzero values whenthe device is in use, it can return a negative errno too.And especially during resuming from system suspend, when runtime pmis not yet up again, -EAGAIN is being returned, so the subsequentpm_runtime_put() call results in a refcount underflow.Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.cThe missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet canlead to the use of wrong `CIDR_POS(c)` for calculating array offsets,which can lead to integer underflow. As a result, it leads to slabout-of-bound access.This patch adds back the IP_SET_HASH_WITH_NET0 macro toip_set_hash_netportnet to address the issue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Avoid NULL pointer access during management transmit cleanupCurrently 'ar' reference is not added in skb_cb.Though this is generally not used during transmit completioncallbacks, on interface removal the remaining idr cleanup callbackuses the ar pointer from skb_cb from management txmgmt_idr. Hence fill themduring transmit call for proper usage to avoid NULL pointer dereference.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/dma-resv: Stop leaking on krealloc() failureCurrently dma_resv_get_fences() will leak the previouslyallocated array if the fence iteration got restarted andthe krealloc_array() fails.Free the old array by hand, and make sure we still clearthe returned *fences so the caller won't end up accessingfreed memory. Some (but not all) of the callers ofdma_resv_get_fences() seem to still trawl through thearray even when dma_resv_get_fences() failed. And let'szero out *num_fences as well for good measure.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/sme: Set new vector length before reallocatingAs part of fixing the allocation of the buffer for SVE state when changingSME vector length we introduced an immediate reallocation of the SVE state,this is also done when changing the SVE vector length for consistency.Unfortunately this reallocation is done prior to writing the new vectorlength to the task struct, meaning the allocation is done with the oldvector length and can lead to memory corruption due to an undersized bufferbeing used.Move the update of the vector length before the allocation to ensure thatthe new vector length is taken into account.For some reason this isn't triggering any problems when running tests onthe arm64 fixes branch (even after repeated tries) but is triggeringissues very often after merge into mainline.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: don't allow to overwrite ENDPOINT0 attributesA bad USB device is able to construct a service connection responsemessage with target endpoint being ENDPOINT0 which is reserved forHTC_CTRL_RSVD_SVC and should not be modified to be used for any otherservices.Reject such service connection responses.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free of new block group that became unusedIf a task creates a new block group and that block group becomes unusedbefore we finish its creation, at btrfs_create_pending_block_groups(),then when btrfs_mark_bg_unused() is called against the block group, weassume that the block group is currently in the list of block groups toreclaim, and we move it out of the list of new block groups and into thelist of unused block groups. This has two consequences:1) We move it out of the list of new block groups associated to the current transaction. So the block group creation is not finished and if we attempt to delete the bg because it's unused, we will not find the block group item in the extent tree (or the new block group tree), its device extent items in the device tree etc, resulting in the deletion to fail due to the missing items;2) We don't increment the reference count on the block group when we move it to the list of unused block groups, because we assumed the block group was on the list of block groups to reclaim, and in that case it already has the correct reference count. However the block group was on the list of new block groups, in which case no extra reference was taken because it's local to the current task. This later results in doing an extra reference count decrement when removing the block group from the unused list, eventually leading the reference count to 0.This second case was caught when running generic/297 from fstests, whichproduced the following assertion failure and stack trace: [589.559] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4299 [589.559] ------------[ cut here ]------------ [589.559] kernel BUG at fs/btrfs/block-group.c:4299! [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.561] Code: 68 62 da c0 (...) [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246 [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000 [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50 [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00 [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100 [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000 [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0 [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [589.564] Call Trace: [589.564] [589.565] ? __die_body+0x1b/0x60 [589.565] ? die+0x39/0x60 [589.565] ? do_trap+0xeb/0x110 [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] ? do_error_trap+0x6a/0x90 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] ? exc_invalid_op+0x4e/0x70 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] ? asm_exc_invalid_op+0x16/0x20 [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] close_ctree+0x35d/0x560 [btrfs] [589.568] ? fsnotify_sb_delete+0x13e/0x1d0 [589.568] ? dispose_list+0x3a/0x50 [589.568] ? evict_inodes+0x151/0x1a0 [589.568] generic_shutdown_super+0x73/0x1a0 [589.569] kill_anon_super+0x14/0x30 [589.569] btrfs_kill_super+0x12/0x20 [btrfs] [589.569] deactivate_locked---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/addrconf: fix a potential refcount underflow for idevNow in addrconf_mod_rs_timer(), reference idev depends on whetherrs_timer is not pending. Then modify rs_timer timeout.There is a time gap in [1], during which if the pending rs_timerbecomes not pending. It will miss to hold idev, but the rs_timeris activated. Thus rs_timer callback function addrconf_rs_timer()will be executed and put idev later without holding idev. A refcountunderflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when);To fix the issue, hold idev if mod_timer() return 0.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix nexthop hash sizeThe nexthop code expects a 31 bit hash, such as what is returned byfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hashreturned by skb_get_hash() can lead to problems related to the fact that'int hash' is a negative number when the MSB is set.In the case of hash threshold nexthop groups, nexthop_select_path_hthr()will disproportionately select the first nexthop group entry. In the caseof resilient nexthop groups, nexthop_select_path_res() may do an out ofbounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535which leads to the following panic:BUG: unable to handle page fault for address: ffffc900025910c8PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0Oops: 0002 [#1] PREEMPT SMP KASAN NOPTICPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:nexthop_select_path+0x197/0xbf0Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85RSP: 0018:ffff88810c36f260 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0PKRU: 55555554Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_initThe line cards array is not freed in the error path ofmlxsw_m_linecards_init(), which can lead to a memory leak. Fix byfreeing the array in the error path, thereby making the error pathidentical to mlxsw_m_linecards_fini().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: qcom: Fix potential memory leakFunction dwc3_qcom_probe() allocates memory for resource structurewhich is pointed by parent_res pointer. This memory is notfreed. This leads to memory leak. Use stack memory to preventmemory leak.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: wraparound mbox producer indexDriver is not handling the wraparound of the mbox producer index correctly.Currently the wraparound happens once u32 max is reached.Bit 31 of the producer index register is special and should be setonly once for the first command. Because the producer index overflowsetting bit31 after a long time, FW goes to initialization sequenceand this causes FW hang.Fix is to wraparound the mbox producer index once it reaches u16 max.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-races around user->unix_inflight.user->unix_inflight is changed under spin_lock(unix_gc_lock),but too_many_unix_fds() reads it locklessly.Let's annotate the write/read accesses to user->unix_inflight.BUG: KCSAN: data-race in unix_attach_fds / unix_inflightwrite to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8value changed: 0x000000000000000c -> 0x000000000000000dReported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: s390/diag: fix racy access of physical cpu number in diag 9c handlerWe do check for target CPU == -1, but this might change at the time weare going to use it. Hold the physical target CPU in a local variable toavoid out-of-bound accesses to the cpu arrays.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (pmbus_core) Fix NULL pointer dereferencePass i2c_client to _pmbus_is_enabled to drop the assumptionthat a regulator device is passed in.This will fix the issue of a NULL pointer dereference when called from_pmbus_get_flags.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ublk: fail to recover device if queue setup is interruptedIn ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() isinterrupted by signal, queues aren't setup successfully yet, so wehave to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can betriggered.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 stateWhen emulating nested VM-Exit, load L1's TSC multiplier if L1's desiredratio doesn't match the current ratio, not if the ratio L1 is using forL2 diverges from the default. Functionally, the end result is the sameas KVM will run L2 with L1's multiplier if L2's multiplier is the default,i.e. checking that L1's multiplier is loaded is equivalent to checking ifL2 has a non-default multiplier.However, the assertion that TSC scaling is exposed to L1 is flawed, asuserspace can trigger the WARN at will by writing the MSR and thenupdating guest CPUID to hide the feature (modifying guest CPUID isallowed anytime before KVM_RUN). E.g. hacking KVM's state_testselftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105 nested_svm_vmexit+0x6af/0x720 [kvm_amd] Call Trace: nested_svm_exit_handled+0x102/0x1f0 [kvm_amd] svm_handle_exit+0xb9/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] ? trace_hardirqs_off+0x4d/0xa0 __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdUnlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled checkinto the if-statement is wrong as KVM needs to ensure L1's multiplier isloaded in the above scenario. Alternatively, the WARN_ON() could simplybe deleted, but that would make KVM's behavior even more subtle, e.g. it'snot immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO whenchecking only tsc_ratio_msr.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' isempty, and then submit 'flush_bio', however, r5l_log_flush_endio()is clearing the list first and then clear the bio, which will causenull-ptr-deref:T1: submit flush ioraid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init submit_bio // io1T2: io1 is doner5l_log_flush_endio list_splice_tail_init // clear the list T3: submit new flush io ... r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init bio_uninit // clear bio->bi_blkg submit_bio // null-ptr-derefFix this problem by clearing bio before clearing the list inr5l_log_flush_endio().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nubus: Partially revert proc_create_single_data() conversionThe conversion to proc_create_single_data() introduced a regressionwhereby reading a file in /proc/bus/nubus results in a seg fault: # grep -r . /proc/bus/nubus/e/ Data read fault at 0x00000020 in Super Data (pc=0x1074c2) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<001074c2>] PDE_DATA+0xc/0x16 SR: 2010 SP: 38284958 a2: 01152370 d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 Process grep (pid: 45, task=142f8727) Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff ver=f Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0x5c/0xb0 [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read+0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos+0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation faultThe proc_create_single_data() conversion does not work becausesingle_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is notequivalent to the original code.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix memleak due to fentry attach failureIf it fails to attach fentry, the allocated bpf trampoline image will beleft in the system. That can be verified by checking /proc/kallsyms.This meamleak can be verified by a simple bpf program as follows: SEC("fentry/trap_init") int fentry_run() { return 0; }It will fail to attach trap_init because this function is freed afterkernel init, and then we can find the trampoline image is left in thesystem by checking /proc/kallsyms. $ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522Note that there are two left bpf trampoline images, that is because thelibbpf will fallback to raw tracepoint if -EINVAL is returned.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Fix OOB and integer underflow when rx packetsMake sure mwifiex_process_mgmt_packet,mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packetnot out-of-bounds access the skb->data buffer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix warning in cifs_smb3_do_mount()This fixes the following warning reported by kernel test robot fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of 'cifs_sb'
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: Fix detection of atomic contextCurrent check for atomic context is not sufficient asz_erofs_decompressqueue_endio can be called under rcu lockfrom blk_mq_flush_plug_list(). See the stacktrace [1]In such case we should hand off the decompression work for asyncprocessing rather than trying to do sync decompression in currentcontext. Patch fixes the detection by checking forrcu_read_lock_any_held() and while at it use more appropriate!in_task() check than in_atomic().Background: Historically erofs would always schedule a kworker fordecompression which would incur the scheduling cost regardless ofthe context. But z_erofs_decompressqueue_endio() may not alwaysbe in atomic context and we could actually benefit from doing thedecompression in z_erofs_decompressqueue_endio() if we are inthread context, for example when running with dm-verity.This optimization was later added in patch [2] which has shownimprovement in performance benchmarks.==============================================[1] Problem stacktrace[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi[name:core&]preempt_count: 0, expected: 0[name:core&]RCU nest depth: 1, expected: 0CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1Hardware name: MT6897 (DT)Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tests: helpers: Avoid a driver uafwhen using __drm_kunit_helper_alloc_drm_device() the driver may bedereferenced by device-managed resources up until the device isfreed, which is typically later than the kunit-managed resource codefrees it. Fix this by simply make the driver device-managed as well.In short, the sequence leading to the UAF is as follows:INIT:Code allocates a struct device as a kunit-managed resource.Code allocates a drm driver as a kunit-managed resource.Code allocates a drm device as a device-managed resource.EXIT:Kunit resource cleanup frees the drm driverKunit resource cleanup puts the struct device, which starts a device-managed resource cleanupdevice-managed cleanup calls drm_dev_put()drm_dev_put() dereferences the (now freed) drm driver -> Boom.Related KASAN message:[55272.551542] ==================================================================[55272.551551] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0xd4/0xe0 [drm][55272.551603] Read of size 8 at addr ffff888127502828 by task kunit_try_catch/10353[55272.551612] CPU: 4 PID: 10353 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ #155[55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021[55272.551626] Call Trace:[55272.551629] [55272.551633] dump_stack_lvl+0x57/0x90[55272.551639] print_report+0xcf/0x630[55272.551645] ? _raw_spin_lock_irqsave+0x5f/0x70[55272.551652] ? drm_dev_put.part.0+0xd4/0xe0 [drm][55272.551694] kasan_report+0xd7/0x110[55272.551699] ? drm_dev_put.part.0+0xd4/0xe0 [drm][55272.551742] drm_dev_put.part.0+0xd4/0xe0 [drm][55272.551783] devres_release_all+0x15d/0x1f0[55272.551790] ? __pfx_devres_release_all+0x10/0x10[55272.551797] device_unbind_cleanup+0x16/0x1a0[55272.551802] device_release_driver_internal+0x3e5/0x540[55272.551808] ? kobject_put+0x5d/0x4b0[55272.551814] bus_remove_device+0x1f1/0x3f0[55272.551819] device_del+0x342/0x910[55272.551826] ? __pfx_device_del+0x10/0x10[55272.551830] ? lock_release+0x339/0x5e0[55272.551836] ? kunit_remove_resource+0x128/0x290 [kunit][55272.551845] ? __pfx_lock_release+0x10/0x10[55272.551851] platform_device_del.part.0+0x1f/0x1e0[55272.551856] ? _raw_spin_unlock_irqrestore+0x30/0x60[55272.551863] kunit_remove_resource+0x195/0x290 [kunit][55272.551871] ? _raw_spin_unlock_irqrestore+0x30/0x60[55272.551877] kunit_cleanup+0x78/0x120 [kunit][55272.551885] ? __kthread_parkme+0xc1/0x1f0[55272.551891] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit][55272.551900] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit][55272.551909] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit][55272.551919] kthread+0x2e7/0x3c0[55272.551924] ? __pfx_kthread+0x10/0x10[55272.551929] ret_from_fork+0x2d/0x70[55272.551935] ? __pfx_kthread+0x10/0x10[55272.551940] ret_from_fork_asm+0x1b/0x30[55272.551948] [55272.551953] Allocated by task 10351:[55272.551956] kasan_save_stack+0x1c/0x40[55272.551962] kasan_set_track+0x21/0x30[55272.551966] __kasan_kmalloc+0x8b/0x90[55272.551970] __kmalloc+0x5e/0x160[55272.551976] kunit_kmalloc_array+0x1c/0x50 [kunit][55272.551984] drm_exec_test_init+0xfa/0x2c0 [drm_exec_test][55272.551991] kunit_try_run_case+0xdd/0x250 [kunit][55272.551999] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit][55272.552008] kthread+0x2e7/0x3c0[55272.552012] ret_from_fork+0x2d/0x70[55272.552017] ret_from_fork_asm+0x1b/0x30[55272.552024] Freed by task 10353:[55272.552027] kasan_save_stack+0x1c/0x40[55272.552032] kasan_set_track+0x21/0x30[55272.552036] kasan_save_free_info+0x27/0x40[55272.552041] __kasan_slab_free+0x106/0x180[55272.552046] slab_free_freelist_hook+0xb3/0x160[55272.552051] __kmem_cache_free+0xb2/0x290[55272.552056] kunit_remove_resource+0x195/0x290 [kunit][55272.552064] kunit_cleanup+0x7---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()The size of array 'priv->ports[]' is INNO_PHY_PORT_NUM.In the for loop, 'i' is used as the index for array 'priv->ports[]'with a check (i > INNO_PHY_PORT_NUM) which indicates thatINNO_PHY_PORT_NUM is allowed value for 'i' in the same loop.This > comparison needs to be changed to >=, otherwise it potentially leadsto an out of bounds write on the next iteration through the loop
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: storvsc: Fix handling of virtual Fibre Channel timeoutsHyper-V provides the ability to connect Fibre Channel LUNs to the hostsystem and present them in a guest VM as a SCSI device. I/O to the vFCdevice is handled by the storvsc driver. The storvsc driver includes apartial integration with the FC transport implemented in the genericportion of the Linux SCSI subsystem so that FC attributes can be displayedin /sys. However, the partial integration means that some aspects of vFCdon't work properly. Unfortunately, a full and correct integration isn'tpractical because of limitations in what Hyper-V provides to the guest.In particular, in the context of Hyper-V storvsc, the FC transport timeoutfunction fc_eh_timed_out() causes a kernel panic because it can't find therport and dereferences a NULL pointer. The original patch that added thecall from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in thisregard.In many cases a timeout is due to a transient condition, so the situationcan be improved by just continuing to wait like with other I/O requestsissued by storvsc, and avoiding the guaranteed panic. For a permanentfailure, continuing to wait may result in a hung thread instead of a panic,which again may be better.So fix the panic by removing the storvsc call to fc_eh_timed_out(). Thisallows storvsc to keep waiting for a response. The change has been testedby users who experienced a panic in fc_eh_timed_out() due to transienttimeouts, and it solves their problem.In the future we may want to deprecate the vFC functionality in storvscsince it can't be fully fixed. But it has current users for whom it isworking well enough, so it should probably stay for a while longer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expandWhile trying to get the subpage blocksize tests running, I hit thefollowing panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198This happens because during btrfs_cont_expand we'll get a page, set itas mapped, and if it's not Uptodate we'll read it. However between theread and re-locking the page we could have called release_folio() on thepage, but left the page in the file mapping. release_folio() can clearthe page private, and thus further down we blow up when we go to modifythe subpage bits.Fix this by putting the set_page_extent_mapped() after the read. Thisis safe because read_folio() will call set_page_extent_mapped() beforeit does the read, and then if we clear page private but leave it on themapping we're completely safe re-setting set_page_extent_mapped(). Withthis patch I can now run generic/476 without panicing.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: install stub fence into potential unused fence pointersWhen using cpu to update page tables, vm update fences are unused.Install stub fence into these fence pointers instead of NULLto avoid NULL dereference when calling dma_fence_wait() on them.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler()rxq can be NULL only when trans_pcie->rxq is NULL and entry->entryis zero. For the case when entry->entry is not equal to 0, rxqwon't be NULL even if trans_pcie->rxq is NULL. Modify checker tocheck for trans_pcie->rxq.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix possible underflow for displays with large vblank[Why]Underflow observed when using a display with a large vblank regionand low refresh rate[How]Simplify calculation of vblank_nomIncrease value for VBlankNomDefaultUS to 800us
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()The variable codec->regmap is often protected by the lockcodec->regmap_lock when is accessed. However, it is accessed withoutholding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap)In my opinion, this may be a harmful race, because if codec->regmap isset to NULL right after the condition is checked, a null-pointerdereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.cTo fix this possible null-pointer dereference caused by data race, themutex_lock coverage is extended to protect the if statement as well as thefunction call to regcache_sync().[ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Return the firmware result upon destroying QP/RQPreviously when destroying a QP/RQ, the result of the firmwaredestruction function was ignored and upper layers weren't informedabout the failure.Which in turn could lead to various problems since when upper layerisn't aware of the failure it continues its operation thinking that therelated QP/RQ was successfully destroyed while it actually wasn't,which could lead to the below kernel WARN.Currently, we return the correct firmware destruction status to upperlayers which in case of the RQ would be mlx5_ib_destroy_wq() whichwas already capable of handling RQ destruction failure or in case ofa QP to destroy_qp_common(), which now would actually warn upon qpdestruction failure.WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuseCPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0fRSP: 0018:ffff8881533e3e78 EFLAGS: 00010287RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ib_uverbs_close+0x1a/0x90 [ib_uverbs] __fput+0x82/0x230 task_work_run+0x59/0x90 exit_to_user_mode_prepare+0x138/0x140 syscall_exit_to_user_mode+0x1d/0x50 ? __x64_sys_close+0xe/0x40 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f8be3ae0abbCode: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abbRDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Put the cdns set active part outside the spin lockThe device may be scheduled during the resume process,so this cannot appear in atomic operations. Sincepm_runtime_set_active will resume suppliers, put setactive outside the spin lock, which is only used toprotect the struct cdns data structure, otherwise thekernel will report the following warning: BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1 Hardware name: Freescale i.MX8QM MEK (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38 __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/client: Fix memory leak in drm_client_modeset_probeWhen a new mode is set to modeset->mode, the previous mode should be freed.This fixes the following kmemleak report:drm_mode_duplicate+0x45/0x220 [drm]drm_client_modeset_probe+0x944/0xf50 [drm]__drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]drm_client_register+0x169/0x240 [drm]ast_pci_probe+0x142/0x190 [ast]local_pci_probe+0xdc/0x180work_for_cpu_fn+0x4e/0xa0process_one_work+0x8b7/0x1540worker_thread+0x70a/0xed0kthread+0x29f/0x340ret_from_fork+0x1f/0x30
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscaleRunning the 'kfree_rcu_test' test case [1] results in a splat [2].The root cause is the kfree_scale_thread thread(s) continue runningafter unloading the rcuscale module. This commit fixes that isue byinvoking kfree_scale_cleanup() from rcu_scale_cleanup() when removingthe rcuscale module.[1] modprobe rcuscale kfree_rcu_test=1 // After some time rmmod rcuscale rmmod torture[2] BUG: unable to handle page fault for address: ffffffffc0601a87 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:0xffffffffc0601a87 Code: Unable to access opcode bytes at 0xffffffffc0601a5d. RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe FS: 0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? kvfree_call_rcu+0xf0/0x3a0 ? kthread+0xf3/0x120 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x1f/0x30 Modules linked in: rfkill sunrpc ... [last unloaded: torture] CR2: ffffffffc0601a87 ---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: microchip: vcap api: Fix possible memory leak for vcap_dup_rule()Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leakoccurs. If kzalloc() for duprule succeeds, but the followingkmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfreethem in the error path.unreferenced object 0xffff122744c50600 (size 192): comm "kunit_try_catch", pid 346, jiffies 4294896122 (age 911.812s) hex dump (first 32 bytes): 10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,... 00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D'... backtrace: [<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8 [<0000000001bedc67>] kmalloc_trace+0x38/0x88 [<00000000b0612f98>] vcap_dup_rule+0x50/0x460 [<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038 [<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494 [<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698 [<00000000c8766299>] kunit_try_run_case+0xe0/0x20c [<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94 [<00000000f6864acf>] kthread+0x2e8/0x374 [<0000000022e639b3>] ret_from_fork+0x10/0x20
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_rbtree: fix overlap expiration walkThe lazy gc on insert that should remove timed-out entries fails to releasethe other half of the interval, if any.Can be reproduced with tests/shell/testcases/sets/0044interval_overlap_0in nftables.git and kmemleak enabled kernel.Second bug is the use of rbe_prev vs. prev pointer.If rbe_prev() returns NULL after at least one iteration, rbe_prev pointsto element that is not an end interval, hence it should not be removed.Lastly, check the genmask of the end interval if this is active in thecurrent generation.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix use-after-freeFix potential use-after-free in l2cap_le_command_rej.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix integer overflow in radeon_cs_parser_initThe type of size is unsigned, if size is 0x40000000, there will be aninteger overflow, size will be zero after size *= sizeof(uint32_t),will cause uninitialized memory to be referenced later
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix net_dev_start_xmit trace event vs skb_transport_offset()After blamed commit, we must be more careful about usingskb_transport_offset(), as reminded us by syzbot:WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14Modules linked in:CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packetRIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ffRSP: 0018:ffffc900002bf700 EFLAGS: 00010293RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffffRBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5eR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0Call Trace:[] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline][] xmit_one net/core/dev.c:3643 [inline][] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660[] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324[] dev_queue_xmit include/linux/netdevice.h:3030 [inline][] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108[] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127[] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline][] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline][] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701[] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289[] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix wrong setting of max_corr_read_errorsThere is no input check when echo md/max_read_errors and overflow mightoccur. Add check of input number.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Handle kvm_arm_init failure correctly in finalize_pkvmCurrently there is no synchronisation between finalize_pkvm() andkvm_arm_init() initcalls. The finalize_pkvm() proceeds happily even ifkvm_arm_init() fails resulting in the following warning on all the CPUsand eventually a HYP panic: | kvm [1]: IPA Size Limit: 48 bits | kvm [1]: Failed to init hyp memory protection | kvm [1]: error initializing Hyp mode: -22 | | | | WARNING: CPU: 0 PID: 0 at arch/arm64/kvm/pkvm.c:226 _kvm_host_prot_finalize+0x30/0x50 | Modules linked in: | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0 #237 | Hardware name: FVP Base RevC (DT) | pstate: 634020c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : _kvm_host_prot_finalize+0x30/0x50 | lr : __flush_smp_call_function_queue+0xd8/0x230 | | Call trace: | _kvm_host_prot_finalize+0x3c/0x50 | on_each_cpu_cond_mask+0x3c/0x6c | pkvm_drop_host_privileges+0x4c/0x78 | finalize_pkvm+0x3c/0x5c | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | Failed to finalize Hyp protection: -22 | dtb=fvp-base-revc.dtb | kvm [95]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:540! | kvm [95]: nVHE call trace: | kvm [95]: [] __kvm_nvhe_hyp_panic+0xac/0xf8 | kvm [95]: [] __kvm_nvhe_handle_host_mem_abort+0x1a0/0x2ac | kvm [95]: [] __kvm_nvhe_handle_trap+0x4c/0x160 | kvm [95]: [] __kvm_nvhe___skip_pauth_save+0x4/0x4 | kvm [95]: ---[ end nVHE call trace ]--- | kvm [95]: Hyp Offset: 0xfffe8db00ffa0000 | Kernel panic - not syncing: HYP panic: | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800 | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000 | VCPU:0000000000000000 | CPU: 3 PID: 95 Comm: kworker/u16:2 Tainted: G W 6.4.0 #237 | Hardware name: FVP Base RevC (DT) | Workqueue: rpciod rpc_async_schedule | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x138/0x33c | nvhe_hyp_panic_handler+0x100/0x184 | new_slab+0x23c/0x54c | ___slab_alloc+0x3e4/0x770 | kmem_cache_alloc_node+0x1f0/0x278 | __alloc_skb+0xdc/0x294 | tcp_stream_alloc_skb+0x2c/0xf0 | tcp_sendmsg_locked+0x3d0/0xda4 | tcp_sendmsg+0x38/0x5c | inet_sendmsg+0x44/0x60 | sock_sendmsg+0x1c/0x34 | xprt_sock_sendmsg+0xdc/0x274 | xs_tcp_send_request+0x1ac/0x28c | xprt_transmit+0xcc/0x300 | call_transmit+0x78/0x90 | __rpc_execute+0x114/0x3d8 | rpc_async_schedule+0x28/0x48 | process_one_work+0x1d8/0x314 | worker_thread+0x248/0x474 | kthread+0xfc/0x184 | ret_from_fork+0x10/0x20 | SMP: stopping secondary CPUs | Kernel Offset: 0x57c5cb460000 from 0xffff800080000000 | PHYS_OFFSET: 0x80000000 | CPU features: 0x00000000,1035b7a3,ccfe773f | Memory Limit: none | ---[ end Kernel panic - not syncing: HYP panic: | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800 | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000 | VCPU:0000000000000000 ]---Fix it by checking for the successfull initialisation of kvm_arm_init()in finalize_pkvm() before proceeding any futher.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext2/dax: Fix ext2_setsize when len is page alignedPAGE_ALIGN(x) macro gives the next highest value which is multiple ofpagesize. But if x is already page aligned then it simply returns x.So, if x passed is 0 in dax_zero_range() function, that means thelength gets passed as 0 to ->iomap_begin().In ext2 it then calls ext2_get_blocks -> max_blocks as 0 and hits bug_onhere in ext2_get_blocks(). BUG_ON(maxblocks == 0);Instead we should be calling dax_truncate_page() here which takescare of it. i.e. it only calls dax_zero_range if the offset is notpage/block aligned.This can be easily triggered with following on fsdax mounted pmemdevice.dd if=/dev/zero of=file count=1 bs=512truncate -s 0 file[79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk[79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff)[93.793207] ------------[ cut here ]------------[93.795102] kernel BUG at fs/ext2/inode.c:637![93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI[93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139[93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610<...>[93.835298] Call Trace:[93.836253] [93.837103] ? lock_acquire+0xf8/0x110[93.838479] ? d_lookup+0x69/0xd0[93.839779] ext2_iomap_begin+0xa7/0x1c0[93.841154] iomap_iter+0xc7/0x150[93.842425] dax_zero_range+0x6e/0xa0[93.843813] ext2_setsize+0x176/0x1b0[93.845164] ext2_setattr+0x151/0x200[93.846467] notify_change+0x341/0x4e0[93.847805] ? lock_acquire+0xf8/0x110[93.849143] ? do_truncate+0x74/0xe0[93.850452] ? do_truncate+0x84/0xe0[93.851739] do_truncate+0x84/0xe0[93.852974] do_sys_ftruncate+0x2b4/0x2f0[93.854404] do_syscall_64+0x3f/0x90[93.855789] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()Change logging from drm_{err,info}() to dev_{err,info}() in functionsmtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will beessential to avoid getting NULL pointer kernel panics if any kindof error happens during AUX transfers happening before the bridgeis attached.This may potentially start happening in a later commit implementingaux-bus support, as AUX transfers will be triggered from the paneldriver (for EDID) before the mtk-dp bridge gets attached, and it'sdone in preparation for the same.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Enhance sanity check while generating attr_listni_create_attr_list uses WARN_ON to catch error cases while generatingattribute list, which only prints out stack trace and may not be enough.This repalces them with more proper error handling flow.[ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e[ 59.673268] #PF: supervisor read access in kernel mode[ 59.678354] #PF: error_code(0x0000) - not-present page[ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0[ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI[ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4[ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014[ 59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860[ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8[ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282[ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe[ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0[ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9[ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180[ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050[ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000[ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0[ 59.787607] Call Trace:[ 59.790271] [ 59.792488] ? __pfx_ni_create_attr_list+0x10/0x10[ 59.797235] ? kernel_text_address+0xd3/0xe0[ 59.800856] ? unwind_get_return_address+0x3e/0x60[ 59.805101] ? __kasan_check_write+0x18/0x20[ 59.809296] ? preempt_count_sub+0x1c/0xd0[ 59.813421] ni_ins_attr_ext+0x52c/0x5c0[ 59.817034] ? __pfx_ni_ins_attr_ext+0x10/0x10[ 59.821926] ? __vfs_setxattr+0x121/0x170[ 59.825718] ? __vfs_setxattr_noperm+0x97/0x300[ 59.829562] ? __vfs_setxattr_locked+0x145/0x170[ 59.833987] ? vfs_setxattr+0x137/0x2a0[ 59.836732] ? do_setxattr+0xce/0x150[ 59.839807] ? setxattr+0x126/0x140[ 59.842353] ? path_setxattr+0x164/0x180[ 59.845275] ? __x64_sys_setxattr+0x71/0x90[ 59.848838] ? do_syscall_64+0x3f/0x90[ 59.851898] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc[ 59.857046] ? stack_depot_save+0x17/0x20[ 59.860299] ni_insert_attr+0x1ba/0x420[ 59.863104] ? __pfx_ni_insert_attr+0x10/0x10[ 59.867069] ? preempt_count_sub+0x1c/0xd0[ 59.869897] ? _raw_spin_unlock_irqrestore+0x2b/0x50[ 59.874088] ? __create_object+0x3ae/0x5d0[ 59.877865] ni_insert_resident+0xc4/0x1c0[ 59.881430] ? __pfx_ni_insert_resident+0x10/0x10[ 59.886355] ? kasan_save_alloc_info+0x1f/0x30[ 59.891117] ? __kasan_kmalloc+0x8b/0xa0[ 59.894383] ntfs_set_ea+0x90d/0xbf0[ 59.897703] ? __pfx_ntfs_set_ea+0x10/0x10[ 59.901011] ? kernel_text_address+0xd3/0xe0[ 59.905308] ? __kernel_text_address+0x16/0x50[ 59.909811] ? unwind_get_return_address+0x3e/0x60[ 59.914898] ? __pfx_stack_trace_consume_entry+0x10/0x10[ 59.920250] ? arch_stack_walk+0xa2/0x100[ 59.924560] ? filter_irq_stacks+0x27/0x80[ 59.928722] ntfs_setxattr+0x405/0x440[ 59.932512] ? __pfx_ntfs_setxattr+0x10/0x10[ 59.936634] ? kvmalloc_node+0x2d/0x120[ 59.940378] ? kasan_save_stack+0x41/0x60[ 59.943870] ? kasan_save_stack+0x2a/0x60[ 59.947719] ? kasan_set_track+0x29/0x40[ 59.951417] ? kasan_save_alloc_info+0x1f/0x30[ 59.955733] ? __kasan_kmalloc+0x8b/0xa0[ 59.959598] ? __kmalloc_node+0x68/0x150[ 59.963163] ? kvmalloc_node+0x2d/0x120[ 59.966490] ? vmemdup_user+0x2b/0xa0---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pstore/ram: Check start of empty przs during initAfter commit 30696378f68a ("pstore/ram: Do not treat empty buffers asvalid"), initialization would assume a prz was valid after seeing thatthe buffer_size is zero (regardless of the buffer start position). Thisunchecked start value means it could be outside the bounds of the buffer,leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ...To avoid this, also check if the prz start is 0 during the initializationphase. If not, the next prz sanity check case will discover it (start >size) and zap the buffer back to a sane state.[kees: update commit log with backtrace and clarifications]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic oneEric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is 'pulled' from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x ...) So dccp_ack_seq() is happily reading stuff past the _dh buffer.BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371[..]Fix this by increasing the stack buffer to also include room forthe extra sequence numbers and all the known dccp packet type headers,then pull again after the initial validation of the basic header.While at it, mark packets invalid that lack 48bit sequence bit butwhere RFC says the type MUST use them.Compile tested only.v2: first skb_header_pointer() now needs to adjust the size to only pull the generic header. (Eric)Heads-up: I intend to remove dccp conntrack support later this year.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warningsWhen ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() runsensor->adev is not set yet.So if either of the dev_warn() calls about unknown values are hit thiswill lead to a NULL pointer deref.Set sensor->adev earlier, with a borrowed ref to avoid making unrollingon errors harder, to fix this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix BUG_ON condition in btrfs_cancel_balancePausing and canceling balance can race to interrupt balance lead to BUG_ONpanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balancedoes not take this race scenario into account.However, the race condition has no other side effects. We can fix that.Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > }
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix handling IPv4 routes with nhidFix handling IPv4 routes referencing a nexthop via its id by replacingcalls to fib_info_nh() with fib_info_nhc().Trying to add an IPv4 route referencing a nextop via nhid: $ ip link set up swp5 $ ip a a 10.0.0.1/24 dev swp5 $ ip nexthop add dev swp5 id 20 via 10.0.0.2 $ ip route add 10.0.1.0/24 nhid 20triggers warnings when trying to handle the route:[ 528.805763] ------------[ cut here ]------------[ 528.810437] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera][ 528.820434] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci][ 528.837485] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G O 6.4.5 #1[ 528.845178] Hardware name: delta,tn48m-dn (DT)[ 528.849641] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera][ 528.857352] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 528.864347] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera][ 528.870135] lr : prestera_k_arb_fib_evt+0xb20/0xd50 [prestera][ 528.876007] sp : ffff80000b20bc90[ 528.879336] x29: ffff80000b20bc90 x28: 0000000000000000 x27: ffff0001374d3a48[ 528.886510] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800[ 528.893683] x23: ffff000101c89148 x22: ffff000101c89000 x21: ffff000101c89200[ 528.900855] x20: ffff00013641fda0 x19: ffff800009d01088 x18: 0000000000000059[ 528.908027] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000[ 528.915198] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000[ 528.922371] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013d2020[ 528.929543] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 : 000000001ca72f86[ 528.936715] x5 : 0000000033399ea7 x4 : 0000000000000000 x3 : ffff0001374d3acc[ 528.943886] x2 : 0000000000000000 x1 : ffff00010200de00 x0 : ffff000134ae3f80[ 528.951058] Call trace:[ 528.953516] __prestera_fi_is_direct+0x2c/0x68 [prestera][ 528.958952] __prestera_router_fib_event_work+0x100/0x158 [prestera][ 528.965348] process_one_work+0x208/0x488[ 528.969387] worker_thread+0x4c/0x430[ 528.973068] kthread+0x120/0x138[ 528.976313] ret_from_fork+0x10/0x20[ 528.979909] ---[ end trace 0000000000000000 ]---[ 528.984998] ------------[ cut here ]------------[ 528.989645] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera][ 528.999628] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci][ 529.016676] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G W O 6.4.5 #1[ 529.024368] Hardware name: delta,tn48m-dn (DT)[ 529.028830] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera][ 529.036539] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 529.043533] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera][ 529.049318] lr : __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera][ 529.055452] sp : ffff80000b20bc60[ 529.058781] x29: ffff80000b20bc60 x28: 0000000000000000 x27: ffff0001374d3a48[ 529.065953] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800[ 529.073126] x23: ffff000101c89148 x22: ffff000101c89148 x21: ffff00013641fda0[ 529.080299] x20: ffff000101c89000 x19: ffff000101c89020 x18: 0000000000000059[ 529.087471] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000[ 529.094642] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000[ 529.101814] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013cee80[ 529.108985] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp6: Fix null-ptr-deref of ip6_null_entry->rt6i_idev in icmp6_dev().With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet thathas the link-local address as src and dst IP and will be forwarded toan external IP in the IPv6 Ext Hdr.For example, the script below generates a packet whose src IP is thelink-local address and dst is updated to 11::. # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $f; done # python3 >>> from socket import * >>> from scapy.all import * >>> >>> SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456" >>> >>> pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR) >>> pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1) >>> >>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW) >>> sk.sendto(bytes(pkt), (DST_ADDR, 0))For such a packet, we call ip6_route_input() to look up a route for thenext destination in these three functions depending on the header type. * ipv6_rthdr_rcv() * ipv6_rpl_srh_rcv() * ipv6_srh_rcv()If no route is found, ip6_null_entry is set to skb, and the followingdst_input(skb) calls ip6_pkt_drop().Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)->rt6i_idev->devas the input device is the loopback interface. Then, we have to check ifskb_rt6_info(skb)->rt6i_idev is NULL or not to avoid NULL pointer dereffor ip6_null_entry.BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01RSP: 0018:ffffc90000003c70 EFLAGS: 00000286RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0PKRU: 55555554Call Trace: ip6_pkt_drop (net/ipv6/route.c:4513) ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5)) ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483) __netif_receive_skb_one_core (net/core/dev.c:5455) process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895) __napi_poll (net/core/dev.c:6460) net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4231) ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135) rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914) sock_sendmsg (net/socket.c:725 net/socket.c:748) __sys_sendto (net/socket.c:2134) __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)RIP: 0033:0x7f9dc751baeaCode: d8 64 89 02 48 c7 c0 ff f---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Fix slicing memory leakThe temporary buffer storing slicing configuration data from user is onlyfreed on error. This is a memory leak. Free the buffer unconditionally.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: check null pointer before accessing when swappingAdd a check to avoid null pointer dereference as below:[ 90.002283] general protection fault, probably for non-canonicaladdress 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI[ 90.002292] KASAN: null-ptr-deref in range[0x0000000000000000-0x0000000000000007][ 90.002346] ? exc_general_protection+0x159/0x240[ 90.002352] ? asm_exc_general_protection+0x26/0x30[ 90.002357] ? ttm_bo_evict_swapout_allowable+0x322/0x5e0 [ttm][ 90.002365] ? ttm_bo_evict_swapout_allowable+0x42e/0x5e0 [ttm][ 90.002373] ttm_bo_swapout+0x134/0x7f0 [ttm][ 90.002383] ? __pfx_ttm_bo_swapout+0x10/0x10 [ttm][ 90.002391] ? lock_acquire+0x44d/0x4f0[ 90.002398] ? ttm_device_swapout+0xa5/0x260 [ttm][ 90.002412] ? lock_acquired+0x355/0xa00[ 90.002416] ? do_raw_spin_trylock+0xb6/0x190[ 90.002421] ? __pfx_lock_acquired+0x10/0x10[ 90.002426] ? ttm_global_swapout+0x25/0x210 [ttm][ 90.002442] ttm_device_swapout+0x198/0x260 [ttm][ 90.002456] ? __pfx_ttm_device_swapout+0x10/0x10 [ttm][ 90.002472] ttm_global_swapout+0x75/0x210 [ttm][ 90.002486] ttm_tt_populate+0x187/0x3f0 [ttm][ 90.002501] ttm_bo_handle_move_mem+0x437/0x590 [ttm][ 90.002517] ttm_bo_validate+0x275/0x430 [ttm][ 90.002530] ? __pfx_ttm_bo_validate+0x10/0x10 [ttm][ 90.002544] ? kasan_save_stack+0x33/0x60[ 90.002550] ? kasan_set_track+0x25/0x30[ 90.002554] ? __kasan_kmalloc+0x8f/0xa0[ 90.002558] ? amdgpu_gtt_mgr_new+0x81/0x420 [amdgpu][ 90.003023] ? ttm_resource_alloc+0xf6/0x220 [ttm][ 90.003038] amdgpu_bo_pin_restricted+0x2dd/0x8b0 [amdgpu][ 90.003210] ? __x64_sys_ioctl+0x131/0x1a0[ 90.003210] ? do_syscall_64+0x60/0x90
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: skb_segment, Call zero copy functions before using skbuff fragsCommit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functionsonce per nskb") added the call to zero copy functions in skb_segment().The change introduced a bug in skb_segment() because skb_orphan_frags()may possibly change the number of fragments or allocate new fragmentsaltogether leaving nrfrags and frag to point to the old values. This cancause a panic with stacktrace like the one below.[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc[ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26[ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0[ 194.021892] Call Trace:[ 194.027422] [ 194.072861] tcp_gso_segment+0x107/0x540[ 194.082031] inet_gso_segment+0x15c/0x3d0[ 194.090783] skb_mac_gso_segment+0x9f/0x110[ 194.095016] __skb_gso_segment+0xc1/0x190[ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem][ 194.107071] dev_qdisc_enqueue+0x16/0x70[ 194.110884] __dev_queue_xmit+0x63b/0xb30[ 194.121670] bond_start_xmit+0x159/0x380 [bonding][ 194.128506] dev_hard_start_xmit+0xc3/0x1e0[ 194.131787] __dev_queue_xmit+0x8a0/0xb30[ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan][ 194.141477] dev_hard_start_xmit+0xc3/0x1e0[ 194.144622] sch_direct_xmit+0xe3/0x280[ 194.147748] __dev_queue_xmit+0x54a/0xb30[ 194.154131] tap_get_user+0x2a8/0x9c0 [tap][ 194.157358] tap_sendmsg+0x52/0x8e0 [tap][ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net][ 194.173631] handle_tx+0xcd/0xe0 [vhost_net][ 194.176959] vhost_worker+0x76/0xb0 [vhost][ 194.183667] kthread+0x118/0x140[ 194.190358] ret_from_fork+0x1f/0x30[ 194.193670] In this case calling skb_orphan_frags() updated nr_frags leaving nrfragslocal variable in skb_segment() stale. This resulted in the code hittingi >= nrfrags prematurely and trying to move to next frag_skb usinglist_skb pointer, which was NULL, and caused kernel panic. Move the callto zero copy functions before using frags and nr_frags.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Add null pointer check in gserial_suspendConsider a case where gserial_disconnect has already clearedgser->ioport. And if gserial_suspend gets called afterwards,it will lead to accessing of gser->ioport and thus causingnull pointer dereference.Avoid this by adding a null pointer check. Added a staticspinlock to prevent gser->ioport from becoming null afterthe newly added null pointer check.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4.2: Rework scratch handling for READ_PLUS (again)I found that the read code might send multiple requests using the samenfs_pgio_header, but nfs4_proc_read_setup() is only called once. This ishow we ended up occasionally double-freeing the scratch buffer, but alsomeans we set a NULL pointer but non-zero length to the xdr scratchbuffer. This results in an oops the first time decoding needs to copysomething to scratch, which frequently happens when decoding READ_PLUShole segments.I fix this by moving scratch handling into the pageio read code. Iprovide a function to allocate scratch space for decoding read replies,and free the scratch buffer when the nfs_pgio_header is freed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: don't assume child devices are all fsl-mc devicesChanges in VFIO caused a pseudo-device to be created as child offsl-mc devices causing a crash [1] when trying to bind a fsl-mcdevice to VFIO. Fix this by checking the device type when enumeratingfsl-mc child devices.[1]Modules linked in:Internal error: Oops: 0000000096000004 [#1] PREEMPT SMPCPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2Hardware name: NXP Layerscape LX2160ARDB (DT)pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mc_send_command+0x24/0x1f0lr : dprc_get_obj_region+0xfc/0x1c0sp : ffff80000a88b900x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffffx14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80Call trace: mc_send_command+0x24/0x1f0 dprc_get_obj_region+0xfc/0x1c0 fsl_mc_device_add+0x340/0x590 fsl_mc_obj_device_add+0xd0/0xf8 dprc_scan_objects+0x1c4/0x340 dprc_scan_container+0x38/0x60 vfio_fsl_mc_probe+0x9c/0xf8 fsl_mc_driver_probe+0x24/0x70 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 device_driver_attach+0x30/0x68 bind_store+0xa8/0x130 drv_attr_store+0x24/0x38 sysfs_kf_write+0x44/0x60 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x334/0x448 ksys_write+0x68/0xf0 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x108 el0_svc_common.constprop.1+0x94/0xf8 do_el0_svc+0x38/0xb0 el0_svc+0x20/0x50 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x174/0x178Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260)---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: da9063: better fix null deref with partial DTTwo versions of the original patch were sent but V1 was merged insteadof V2 due to a mistake.So update to V2.The advantage of V2 is that it completely avoids dereferencing the pointer,even just to take the address, which may fix problems with some compilers.Both versions work on my gcc 9.4 but use the safer one.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6mr: Fix skb_under_panic in ip6mr_cache_report()skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x152/0x1d0 Call Trace: skb_push+0xc4/0xe0 ip6mr_cache_report+0xd69/0x19b0 reg_vif_xmit+0x406/0x690 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 vlan_dev_hard_start_xmit+0x3ab/0x5c0 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 neigh_connected_output+0x3ed/0x570 ip6_finish_output2+0x5b5/0x1950 ip6_finish_output+0x693/0x11c0 ip6_output+0x24b/0x880 NF_HOOK.constprop.0+0xfd/0x530 ndisc_send_skb+0x9db/0x1400 ndisc_send_rs+0x12a/0x6c0 addrconf_dad_completed+0x3c9/0xea0 addrconf_dad_work+0x849/0x1420 process_one_work+0xa22/0x16e0 worker_thread+0x679/0x10c0 ret_from_fork+0x28/0x60 ret_from_fork_asm+0x11/0x20When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().reg_vif_xmit() ip6mr_cache_report() skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4And skb_push declared as: void *skb_push(struct sk_buff *skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: fix mem leak in capture user mappingsThis commit fixes a memory leak caused when clearing the user_mappingsinfo when a new context is opened immediately after user_mapping iscaptured and a hard reset is performed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race issue between cpu buffer write and swapWarning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142 rb_commit+0x402/0x4a0 Call Trace: ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_event_sched_switch+0x23c/0x2c0 __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0It is because the race between writing event into cpu buffer and swappingcpu buffer through file per_cpu/cpu0/snapshot: Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1 -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b; buffer_b->buffers[cpu] = cpu_buffer_a; // 2. cpu_buffer has swapped here. rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer' [...] // has not changed here. return NULL; } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. Reserve event from 'cpu_buffer_a'. ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!! rb_commit(cpu_buffer) rb_end_commit() // 6. WARN for the wrong 'committing' state !!!Based on above analysis, we can easily reproduce by following testcase: ``` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR}/buffer_size_kb echo "sched:sched_switch" > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & ```To fix it, IIUC, we can use smp_call_function_single() to do the swap onthe target cpu where the buffer is located, so that above race would beavoided.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dcb: choose correct policy to parse DCB_ATTR_BCNThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],which is introduced in commit 859ee3c43812 ("DCB: Add support for DCBBCN"). Please see the comment in below codestatic int dcbnl_bcn_setcfg(...){ ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ...}That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nestattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But thefollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.By looking up the associated nla_policy for dcbnl_bcn_attrs. We can findthe beginning part of these two policies are "same".static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},};static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},};Therefore, the current code is buggy and thisnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and usethe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.Hence use the correct policy dcbnl_bcn_nest to parse the nestedtb[DCB_ATTR_BCN] TLV.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix memory leak in mes self testThe fences associated with mes queue have to be freedup during amdgpu_ring_fini.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_createThe memory pointed to by the fs->any pointer is not freed in the errorpath of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.Fix by freeing the memory in the error path, thereby making the error pathidentical to mlx5e_fs_tt_redirect_any_destroy().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone earlyNot calling hci_(dis)connect_cfm before deleting conn referred to by asocket generally results to use-after-free.When cleaning up SCO connections when the parent ACL is deleted tooearly, use hci_conn_failed to do the connection cleanup properly.We also need to clean up ISO connections in a similar situation whenconnecting has started but LE Create CIS is not yet sent, so do it toohere.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent use-after-free by freeing the cfile laterIn smb2_compound_op we have a possible use-after-freewhich can cause hard to debug problems later on.This was revealed during stress testing with KASAN enabledkernel. Fixing it by moving the cfile free call toa few lines below, after the usage.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()Smatch reports:drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()warn: missing unwind goto?After geting irq, if ret < 0, it will return without error handling tofree memory.Just add error handling to fix this problem.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix null-ptr-deref of mreplace in raid10_sync_requestThere are two check of 'mreplace' in raid10_sync_request(). In the firstcheck, 'need_replace' will be set and 'mreplace' will be used later ifno-Faulty 'mreplace' exists, In the second check, 'mreplace' will beset to NULL if it is Faulty, but 'need_replace' will not be changedaccordingly. null-ptr-deref occurs if Faulty is set between two check.Fix it by merging two checks into one. And replace 'need_replace' with'mreplace' because their values are always the same.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: avoid possible NULL skb pointer dereferenceIn 'mwifiex_handle_uap_rx_forward()', always check the valuereturned by 'skb_copy()' to avoid potential NULL pointerdereference in 'mwifiex_uap_queue_bridged_pkt()', and droporiginal skb in case of copying failure.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mdp3: Fix resource leaks in of_find_device_by_nodeUse put_device to release the object get through of_find_device_by_node,avoiding resource leaks.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix potential use-after-free when clear keysSimilar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free inhci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu()call.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfsAs the ramfs-based tmpfs uses ramfs_init_fs_context() for theinit_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb()to free it and avoid a memory leak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: xsk: Fix crash on regular rq reactivationWhen the regular rq is reactivated after the XSK socket is closedit could be reading stale cqes which eventually corrupts the rq.This leads to no more traffic being received on the regular rq and acrash on the next close or deactivation of the rq.Kal Cuttler Conely reported this issue as a crash on the releasepath when the xdpsock sample program is stopped (killed) and restartedin sequence while traffic is running.This patch flushes all cqes when during the rq flush. The cqe flushingis done in the reset state of the rq. mlx5e_rq_to_ready code is movedinto the flush function to allow for this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:modpost: fix off by one in is_executable_section()The > comparison should be >= to prevent an out of bounds arrayaccess.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()KCSAN found an issue in obj_stock_flush_required():stock->cached_objcg can be reset between the check and dereference:==================================================================BUG: KCSAN: data-race in drain_all_stock / drain_obj_stockwrite to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [inline] __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913 __fput+0x3bf/0x570 fs/file_table.c:329 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: obj_stock_flush_required mm/memcontrol.c:3319 [inline] drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [inline] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [inline] __se_sys_setsockopt net/socket.c:2279 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff8881382d52c0 -> 0xffff888138893740Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses tostock->cached_objcg.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr()Here is a BUG report from syzbot:BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632Call Trace: ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 vfs_listxattr fs/xattr.c:457 [inline] listxattr+0x293/0x2d0 fs/xattr.c:804Fix the logic of ea_all iteration. When the ea->name_len is 0,return immediately, or Add2Ptr() would visit invalid memoryin the next loop.[almaz.alexandrovich@paragon-software.com: lines of the patch have changed]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()When blkg_alloc() is called to allocate a blkcg_gq structurewith the associated blkg_iostat_set's, there are 2 fields withinblkg_iostat_set that requires proper initialization - blkg & sync.The former field was introduced by commit 3b8cc6298724 ("blk-cgroup:Optimize blkcg_rstat_flush()") while the later one was introduced bycommit f73316482977 ("blk-cgroup: reimplement basic IO stats usingcgroup rstat").Unfortunately those fields in the blkg_iostat_set's are not properlyre-initialized when they are cleared in v1's blkcg_reset_stats(). Thiscan lead to a kernel panic due to NULL pointer access of the blkgpointer. The missing initialization of sync is less problematic andcan be a problem in a debug kernel due to missing lockdep initialization.Fix these problems by re-initializing them after memory clearing.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: fix of_iomap memory leakSmatch reports:drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn: 'base' from of_iomap() not released on lines: 496.This problem was also found in linux-next. In mtk_clk_simple_probe(),base is not released when handling errorsif clk_data is not existed, which may cause a leak.So free_base should be added here to release base.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: mediatek: vpu: fix NULL ptr dereferenceIf pdev is NULL, then it is still dereferenced.This fixes this smatch warning:drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix xsk_diag use-after-free error during socket cleanupFix a use-after-free error that is possible if the xsk_diag interfaceis used after the socket has been unbound from the device. This canhappen either due to the socket being closed or the devicedisappearing. In the early days of AF_XDP, the way we tested that asocket was not bound to a device was to simply check if the netdevicepointer in the xsk socket structure was NULL. Later, a better systemwas introduced by having an explicit state variable in the xsk socketstruct. For example, the state of a socket that is on the way to beingclosed and has been unbound from the device is XSK_UNBOUND.The commit in the Fixes tag below deleted the old way of signallingthat a socket is unbound, setting dev to NULL. This in the belief thatall code using the old way had been exterminated. That wasunfortunately not true as the xsk diagnostics code was still using theold way and thus does not work as intended when a socket is goingdown. Fix this by introducing a test against the state variable. Ifthe socket is in the state XSK_UNBOUND, simply abort the diagnostic'snetlink operation.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powercap: arm_scmi: Remove recursion while parsing zonesPowercap zones can be defined as arranged in a hierarchy of trees and whenregistering a zone with powercap_register_zone(), the kernel powercapsubsystem expects this to happen starting from the root zones down to theleaves; on the other side, de-registration by powercap_deregister_zone()must begin from the leaf zones.Available SCMI powercap zones are retrieved dynamically from the platformat probe time and, while any defined hierarchy between the zones isdescribed properly in the zones descriptor, the platform returns theavailables zones with no particular well-defined order: as a consequence,the trees possibly composing the hierarchy of zones have to be somehowwalked properly to register the retrieved zones from the root.Currently the ARM SCMI Powercap driver walks the zones using a recursivealgorithm; this approach, even though correct and tested can lead to kernelstack overflow when processing a returned hierarchy of zones composed byparticularly high trees.Avoid possible kernel stack overflow by substituting the recursive approachwith an iterative one supported by a dynamically allocated stack-like datastructure.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't check PageError in __extent_writepage__extent_writepage currenly sets PageError whenever any error happens,and the also checks for PageError to decide if to call error handling.This leads to very unclear responsibility for cleaning up on errors.In the VM and generic writeback helpers the basic idea is that onceI/O is fired off all error handling responsibility is delegated to theend I/O handler. But if that end I/O handler sets the PageError bit,and the submitter checks it, the bit could in some cases leak into thesubmission context for fast enough I/O.Fix this by simply not checking PageError and just using the localret variable to check for submission errors. This also fundamentallysolves the long problem documented in a comment in __extent_writepageby never leaking the error bit into the submission context.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: snic: Fix possible memory leak if device_add() failsIf device_add() returns error, the name allocated by dev_set_name() needsbe freed. As the comment of device_add() says, put_device() should be usedto give up the reference in the error path. So fix this by callingput_device(), then the name can be freed in kobject_cleanp().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: cpumap: Fix memory leak in cpu_map_update_elemSyzkaller reported a memory leak as follows:BUG: memory leakunreferenced object 0xff110001198ef748 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J........... 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(....... backtrace: [] __cpu_map_entry_alloc+0xf7/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff110001198ef528 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __cpu_map_entry_alloc+0x260/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff1100010fd93d68 (size 8): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [] kvmalloc_node+0x11e/0x170 [] __cpu_map_entry_alloc+0x2f0/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6In the cpu_map_update_elem flow, when kthread_stop is called beforecalling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bitof kthread has been set by kthread_stop, the threadfn of rcpu->kthreadwill never be executed, and rcpu->refcnt will never be 0, which willlead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot bereleased.Calling kthread_stop before executing kthread's threadfn will return-EINTR. We can complete the release of memory resources in this state.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: fix bulk_move corruption when adding a entryWhen the resource is the first in the bulk_move range, adding it again(thus moving it to the tail) will corrupt the list since the firstpointer is not moved. This eventually lead to null pointer deref inttm_lru_bulk_move_del()
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-freeStruct pcie_link_state->downstream is a pointer to the pci_dev of function0. Previously we retained that pointer when removing function 0, andsubsequent ASPM policy changes dereferenced it, resulting in ause-after-free warning from KASAN, e.g.: # echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove # echo powersave > /sys/module/pcie_aspm/parameters/policy BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500 Call Trace: kasan_report+0xae/0xe0 pcie_config_aspm_link+0x42d/0x500 pcie_aspm_set_policy+0x8e/0x1a0 param_attr_store+0x162/0x2c0 module_attr_store+0x3e/0x80PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPMControl value in all functions of multi-function devices.Disable ASPM and free the pcie_link_state when any child function isremoved so we can discard the dangling pcie_link_state->downstream pointerand maintain the same ASPM Control configuration for all functions.[bhelgaas: commit log and comment]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: don't reset unchangable mount option in f2fs_remount()syzbot reports a bug as below:general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASANRIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942Call Trace: lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691 __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline] _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300 __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100 f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116 f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664 f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838 vfs_fallocate+0x54b/0x6b0 fs/open.c:324 ksys_fallocate fs/open.c:347 [inline] __do_sys_fallocate fs/open.c:355 [inline] __se_sys_fallocate fs/open.c:353 [inline] __x64_sys_fallocate+0xbd/0x100 fs/open.c:353 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/0xcdThe root cause is race condition as below:- since it tries to remount rw filesystem, so that do_remount won'tcall sb_prepare_remount_readonly to block fallocate, there may be racecondition in between remount and fallocate.- in f2fs_remount(), default_options() will reset mount option to defaultone, and then update it based on result of parse_options(), so there isa hole which race condition can happen.Thread A Thread B- f2fs_fill_super - parse_options - clear_opt(READ_EXTENT_CACHE)- f2fs_remount - default_options - set_opt(READ_EXTENT_CACHE) - f2fs_fallocate - f2fs_insert_range - f2fs_drop_extent_tree - __drop_extent_tree - __may_extent_tree - test_opt(READ_EXTENT_CACHE) return true - write_lock(&et->lock) access NULL pointer - parse_options - clear_opt(READ_EXTENT_CACHE)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: imxfb: Removed unneeded release_mem_regionRemove unnecessary release_mem_region from the error path to preventmem region from being released twice, which could avoid resource leakor other unexpected issues.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix potential NULL pointer dereferenceKlocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validatepointer before dereferencing the pointer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:FS: JFS: Fix null-ptr-deref Read in txBegin Syzkaller reported an issue where txBegin may be called on a superblock in a read-only mounted filesystem which leads to NULL pointer deref. This could be solved by checking if the filesystem is read-only before calling txBegin, and returning with appropiate error code.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: wait interruptibly for request completions on exitWHen the ring exits, cleanup is done and the final cancelation andwaiting on completions is done by io_ring_exit_work. That function isinvoked by kworker, which doesn't take any signals. Because of that, itdoesn't really matter if we wait for completions in TASK_INTERRUPTIBLEor TASK_UNINTERRUPTIBLE state. However, it does matter to the hung taskdetection checker!Normally we expect cancelations and completions to happen ratherquickly. Some test cases, however, will exit the ring and park theowning task stopped (eg via SIGSTOP). If the owning task needs to runtask_work to complete requests, then io_ring_exit_work won't make anyprogress until the task is runnable again. Hence io_ring_exit_work cantrigger the hung task detection, which is particularly problematic ifpanic-on-hung-task is enabled.As the ring exit doesn't take signals to begin with, have it waitinterruptibly rather than uninterruptibly. io_uring has a separatestuck-exit warning that triggers independently anyway, so we're notreally missing anything by making this switch.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Do not reset dql stats on NON_FATAL errAll ibmvnic resets, make a call to netdev_tx_reset_queue() whenre-opening the device. netdev_tx_reset_queue() resets the num_queuedand num_completed byte counters. These stats are used in Byte QueueLimit (BQL) algorithms. The difference between these two stats tracksthe number of bytes currently sitting on the physical NIC. ibmvnicincreases the number of queued bytes though calls tonetdev_tx_sent_queue() in the drivers xmit function. When, VIOS reportsthat it is done transmitting bytes, the ibmvnic device increases thenumber of completed bytes through calls to netdev_tx_completed_queue().It is important to note that the driver batches its transmit calls andnum_queued is increased every time that an skb is added to the nextbatch, not necessarily when the batch is sent to VIOS for transmission.Unlike other reset types, a NON FATAL reset will not flush the sub crqtx buffers. Therefore, it is possible for the batched skb array to bepartially full. So if there is call to netdev_tx_reset_queue() whenre-opening the device, the value of num_queued (0) would not accountfor the skb's that are currently batched. Eventually, when the batchis sent to VIOS, the call to netdev_tx_completed_queue() would increasenum_completed to a value greater than the num_queued. This causes aBUG_ON crash:ibmvnic 30000002: Firmware reports error, cause: adapter problem.Starting recovery...ibmvnic 30000002: tx error 600ibmvnic 30000002: tx error 600ibmvnic 30000002: tx error 600ibmvnic 30000002: tx error 600------------[ cut here ]------------kernel BUG at lib/dynamic_queue_limits.c:27!Oops: Exception in kernel mode, sig: 5[....]NIP dql_completed+0x28/0x1c0LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]Call Trace:ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]__handle_irq_event_percpu+0x98/0x270---[ end trace ]---Therefore, do not reset the dql stats when performing a NON_FATAL reset.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: qcom: fix storing port config out-of-boundsThe 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14),however we index it starting from 1, not 0, to match real port numbers.This can lead to writing port config past 'pconfig' bounds andoverwriting next member of 'qcom_swrm_ctrl' struct. Reported also bysmatch: drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: lpc32xx: Remove handling of PWM channelsBecause LPC32xx PWM controllers have only a single output which isregistered as the only PWM device/channel per controller, it is known inadvance that pwm->hwpwm value is always 0. On basis of this factsimplify the code by removing operations with pwm->hwpwm, there is nocontrols which require channel number as input.Even though I wasn't aware at the time when I forward ported that patch,this fixes a null pointer dereference as lpc32xx->chip.pwms is NULLbefore devm_pwmchip_add() is called.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/acpi: Fix a use-after-free in cxl_parse_cfmws()KASAN and KFENCE detected an user-after-free in the CXL driver. Thishappens in the cxl_decoder_add() fail path. KASAN prints the followingerror: BUG: KASAN: slab-use-after-free in cxl_parse_cfmws (drivers/cxl/acpi.c:299)This happens in cxl_parse_cfmws(), where put_device() is called,releasing cxld, which is accessed later.Use the local variables in the dev_err() instead of pointing to thereleased memory. Since the dev_err() is printing a resource, change the opencoded print format to use the %pr format specifier.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kobject: Add sanity check for kset->kobj.ktype in kset_register()When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset);A null pointer dereference exception is occurred:[ 4453.568337] Unable to handle kernel NULL pointer dereference at \virtual address 0000000000000028... ...[ 4453.810361] Call trace:[ 4453.813062] kobject_get_ownership+0xc/0x34[ 4453.817493] kobject_add_internal+0x98/0x274[ 4453.822005] kset_register+0x5c/0xb4[ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]... ...Because I didn't initialize my_kset.kobj.ktype.According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype.So add sanity check to make sure kset->kobj.ktype is not NULL.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas_flash: allow user copy to flash block cache objectsWith hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the/proc/powerpc/rtas/firmware_update interface to prepare a systemfirmware update yields a BUG(): kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2 Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries NIP: c0000000005991d0 LR: c0000000005991cc CTR: 0000000000000000 REGS: c0000000148c76a0 TRAP: 0700 Not tainted (6.5.0-rc3+) MSR: 8000000000029033 CR: 24002242 XER: 0000000c CFAR: c0000000001fbd34 IRQMASK: 0 [ ... GPRs omitted ... ] NIP usercopy_abort+0xa0/0xb0 LR usercopy_abort+0x9c/0xb0 Call Trace: usercopy_abort+0x9c/0xb0 (unreliable) __check_heap_object+0x1b4/0x1d0 __check_object_size+0x2d0/0x380 rtas_flash_write+0xe4/0x250 proc_reg_write+0xfc/0x160 vfs_write+0xfc/0x4e0 ksys_write+0x90/0x160 system_call_exception+0x178/0x320 system_call_common+0x160/0x2c4The blocks of the firmware image are copied directly from user memoryto objects allocated from flash_block_cache, so flash_block_cache mustbe created using kmem_cache_create_usercopy() to mark it safe for useraccess.[mpe: Trim and indent oops]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix possible panic during hotplug removeDuring hotplug remove it is possible that the update counters workmight be pending, and may run after memory has been freed.Cancel the update counters work before freeing memory.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix disconnect vs accept raceDespite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero inrecvmsg()"), the mptcp protocol is still prone to a race betweendisconnect() (or shutdown) and accept.The root cause is that the mentioned commit checks the msk-levelflag, but mptcp_stream_accept() does acquire the msk-level lock,as it can rely directly on the first subflow lock.As reported by Christoph than can lead to a race where an msksocket is accepted after that mptcp_subflow_queue_clean() releasesthe listener socket lock and just before it takes destructiveactions leading to the following splat:BUG: kernel NULL pointer dereference, address: 0000000000000012PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0Oops: 0000 [#1] PREEMPT SMPCPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896aRBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Address the issue by temporary removing the pending request socketfrom the accept queue, so that racing accept() can't touch them.After depleting the msk - the ssk still exists, as plain TCP sockets,re-insert them into the accept queue, so that later inet_csk_listen_stop()will complete the tcp socket disposal.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not ignore genmask when looking up chain by idWhen adding a rule to a chain referring to its ID, if that chain had beendeleted on the same batch, the rule might end up referring to a deletedchain.This will lead to a WARNING like following:[ 33.098431] ------------[ cut here ]------------[ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260[ 33.099217] Modules linked in:[ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409[ 33.099726] Workqueue: events nf_tables_trans_destroy_work[ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260[ 33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7[ 33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202[ 33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000[ 33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000[ 33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500[ 33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10[ 33.103762] FS: 0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000[ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0[ 33.104872] PKRU: 55555554[ 33.104999] Call Trace:[ 33.105113] [ 33.105214] ? show_regs+0x72/0x90[ 33.105371] ? __warn+0xa5/0x210[ 33.105520] ? nf_tables_chain_destroy+0x23d/0x260[ 33.105732] ? report_bug+0x1f2/0x200[ 33.105902] ? handle_bug+0x46/0x90[ 33.106546] ? exc_invalid_op+0x19/0x50[ 33.106762] ? asm_exc_invalid_op+0x1b/0x20[ 33.106995] ? nf_tables_chain_destroy+0x23d/0x260[ 33.107249] ? nf_tables_chain_destroy+0x30/0x260[ 33.107506] nf_tables_trans_destroy_work+0x669/0x680[ 33.107782] ? mark_held_locks+0x28/0xa0[ 33.107996] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10[ 33.108294] ? _raw_spin_unlock_irq+0x28/0x70[ 33.108538] process_one_work+0x68c/0xb70[ 33.108755] ? lock_acquire+0x17f/0x420[ 33.108977] ? __pfx_process_one_work+0x10/0x10[ 33.109218] ? do_raw_spin_lock+0x128/0x1d0[ 33.109435] ? _raw_spin_lock_irq+0x71/0x80[ 33.109634] worker_thread+0x2bd/0x700[ 33.109817] ? __pfx_worker_thread+0x10/0x10[ 33.110254] kthread+0x18b/0x1d0[ 33.110410] ? __pfx_kthread+0x10/0x10[ 33.110581] ret_from_fork+0x29/0x50[ 33.110757] [ 33.110866] irq event stamp: 1651[ 33.111017] hardirqs last enabled at (1659): [] __up_console_sem+0x79/0xa0[ 33.111379] hardirqs last disabled at (1666): [] __up_console_sem+0x5e/0xa0[ 33.111740] softirqs last enabled at (1616): [] __irq_exit_rcu+0x9e/0xe0[ 33.112094] softirqs last disabled at (1367): [] __irq_exit_rcu+0x9e/0xe0[ 33.112453] ---[ end trace 0000000000000000 ]---This is due to the nft_chain_lookup_byid ignoring the genmask. After thischange, adding the new rule will fail as it will not find the chain.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: tighten bounds checking in decode_message()Copy the bounds checking from encode_message() to decode_message().This patch addresses the following concerns. Ensure that there isenough space for at least one header so that we don't have a negativesize later. if (msg_hdr_len < sizeof(*trans_hdr))Ensure that we have enough space to read the next header from themsg->data. if (msg_len > msg_hdr_len - sizeof(*trans_hdr)) return -EINVAL;Check that the trans_hdr->len is not below the minimum size: if (hdr_len < sizeof(*trans_hdr))This minimum check ensures that we don't corrupt memory indecode_passthrough() when we do. memcpy(out_trans->data, in_trans->data, len - sizeof(in_trans->hdr));And finally, use size_add() to prevent an integer overflow: if (size_add(msg_len, hdr_len) > msg_hdr_len)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()rules is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrules to avoid OOB writing or NULL pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/platform/uv: Use alternate source for socket to node dataThe UV code attempts to build a set of tables to allow it to dobidirectional socket<=>node lookups.But when nr_cpus is set to a smaller number than actually present, thecpu_to_node() mapping information for unused CPUs is not available tobuild_socket_tables(). This results in skipping some nodes or socketswhen creating the tables and leaving some -1's for later code to trip.over, causing oopses.The problem is that the socket<=>node lookups are created by doing aloop over all CPUs, then looking up the CPU's APICID and socket. Butif a CPU is not present, there is no way to start this lookup.Instead of looping over all CPUs, take CPUs out of the equationentirely. Loop over all APICIDs which are mapped to a valid NUMA node.Then just extract the socket-id from the APICID.This avoid tripping over disabled CPUs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix slab-use-after-free in decode_session6When the xfrm device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when the xfrm device sends IPv6 packets.The stack information is as follows:BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890Read of size 1 at addr ffff8881111458ef by task swapper/3/0CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014Call Trace:dump_stack_lvl+0xd9/0x150print_address_description.constprop.0+0x2c/0x3c0kasan_report+0x11d/0x130decode_session6+0x103f/0x1890__xfrm_decode_session+0x54/0xb0xfrmi_xmit+0x173/0x1ca0dev_hard_start_xmit+0x187/0x700sch_direct_xmit+0x1a3/0xc30__qdisc_run+0x510/0x17a0__dev_queue_xmit+0x2215/0x3b10neigh_connected_output+0x3c2/0x550ip6_finish_output2+0x55a/0x1550ip6_finish_output+0x6b9/0x1270ip6_output+0x1f1/0x540ndisc_send_skb+0xa63/0x1890ndisc_send_rs+0x132/0x6f0addrconf_rs_timer+0x3f1/0x870call_timer_fn+0x1a0/0x580expire_timers+0x29b/0x4b0run_timer_softirq+0x326/0x910__do_softirq+0x1d4/0x905irq_exit_rcu+0xb7/0x120sysvec_apic_timer_interrupt+0x97/0xc0asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:intel_idle_hlt+0x23/0x30Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4RSP: 0018:ffffc90000197d78 EFLAGS: 00000246RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9dR10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000cpuidle_enter_state+0xd3/0x6f0cpuidle_enter+0x4e/0xa0do_idle+0x2fe/0x3c0cpu_startup_entry+0x18/0x20start_secondary+0x200/0x290secondary_startup_64_no_verify+0x167/0x16bAllocated by task 939:kasan_save_stack+0x22/0x40kasan_set_track+0x25/0x30__kasan_slab_alloc+0x7f/0x90kmem_cache_alloc_node+0x1cd/0x410kmalloc_reserve+0x165/0x270__alloc_skb+0x129/0x330inet6_ifa_notify+0x118/0x230__ipv6_ifa_notify+0x177/0xbe0addrconf_dad_completed+0x133/0xe00addrconf_dad_work+0x764/0x1390process_one_work+0xa32/0x16f0worker_thread+0x67d/0x10c0kthread+0x344/0x440ret_from_fork+0x1f/0x30The buggy address belongs to the object at ffff888111145800which belongs to the cache skbuff_small_head of size 640The buggy address is located 239 bytes inside offreed 640-byte region [ffff888111145800, ffff888111145a80)As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbindWhen unbinding pasid - a race condition exists vs outstanding page faults.To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbindSince refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory")Fix this issue by changing refcount_dec to refcount_dec_and_testto explicitly handle refcount=1.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAFib_dealloc_device() should be called only after device cleanup. Fix thedealloc sequence.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFFThe previous commit 954d1fa1ac93 ("macvlan: Add netlink attribute forbroadcast cutoff") added one additional attribute namedIFLA_MACVLAN_BC_CUTOFF to allow broadcast cutfoff.However, it forgot to describe the nla_policy at macvlan_policy(drivers/net/macvlan.c). Hence, this suppose NLA_S32 (4 bytes) integercan be faked as empty (0 bytes) by a malicious user, which could leadsto OOB in heap just like CVE-2023-3773.To fix it, this commit just completes the nla_policy description forIFLA_MACVLAN_BC_CUTOFF. This enforces the length check and avoids thepotential OOB read.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()The following call trace was observed:localhost kernel: nvme nvme0: NVME-FC{0}: controller connect completelocalhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]localhost kernel: Call Trace:localhost kernel: dump_stack_lvl+0x57/0x7dlocalhost kernel: check_preemption_disabled+0xc8/0xd0localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]Use raw_smp_processor_id() instead of smp_processor_id().Also use queue_work() across the driver instead of queue_work_on() thusavoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add max vqp 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 max vqp attr to avoidsuch bugs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctxwhen mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memorypointed by 'in' is not released, which will cause memory leak. Move memoryrelease after mlx5_cmd_exec.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urbThe syzbot fuzzer identified a problem in the usbnet driver:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc9000463f568 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0Call Trace: usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 [inline] netdev_start_xmit include/linux/netdevice.h:4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594...This bug is caused by the fact that usbnet trusts the bulk endpointaddresses its probe routine receives in the driver_info structure, andit does not check to see that these endpoints actually exist and havethe expected type and directions.The fix is simply to add such a check.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: amd-pstate: fix global sysfs attribute typeIn commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")the "amd_pstate" attributes where moved from a dedicated kobject to thecpu root kobject.While the dedicated kobject expects to contain kobj_attributes the rootkobject needs device_attributes.As the changed arguments are not used by the callbacks it works most ofthe time.However CFI will detect this issue:[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)...[ 4947.849409] Call Trace:[ 4947.849410] [ 4947.849411] ? __warn+0xcf/0x1c0[ 4947.849414] ? dev_attr_show+0x24/0x60[ 4947.849415] ? report_cfi_failure+0x4e/0x60[ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0[ 4947.849419] ? __cfi_show_status+0x10/0x10[ 4947.849420] ? handle_bug+0x4f/0x90[ 4947.849421] ? exc_invalid_op+0x1a/0x60[ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20[ 4947.849424] ? __cfi_show_status+0x10/0x10[ 4947.849425] ? dev_attr_show+0x24/0x60[ 4947.849426] sysfs_kf_seq_show+0xa6/0x110[ 4947.849433] seq_read_iter+0x16c/0x4b0[ 4947.849436] vfs_read+0x272/0x2d0[ 4947.849438] ksys_read+0x72/0xe0[ 4947.849439] do_syscall_64+0x76/0xb0[ 4947.849440] ? do_user_addr_fault+0x252/0x650[ 4947.849442] ? exc_page_fault+0x7a/0x1b0[ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: mark requests for GuC virtual engines to avoid use-after-freeReferences to i915_requests may be trapped by userspace inside async_file or dmabuf (dma-resv) and held indefinitely across differentproceses. To counter-act the memory leaks, we try to not to keepreferences from the request past their completion.On the other side on fence release we need to know if rq->engineis valid and points to hw engine (true for non-virtual requests).To make it possible extra bit has been added to rq->execution_mask,for marking virtual engines.(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hyperv: avoid struct memcpy overrun warningA previous patch addressed the fortified memcpy warning for mostbuilds, but I still see this one with gcc-9:In file included from include/linux/string.h:254, from drivers/hid/hid-hyperv.c:8:In function 'fortify_memcpy_chk', inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~My guess is that the WARN_ON() itself is what confuses gcc, so it nolonger sees that there is a correct range check. Rework the code in away that helps readability and avoids the warning.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()The "exc->key_len" is a u16 that comes from the user. If it's overIW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/core: initialize damo_filter->list from damos_new_filter()damos_new_filter() is not initializing the list field of newly allocatedfilter object. However, DAMON sysfs interface and DAMON_RECLAIM are notinitializing it after calling damos_new_filter(). As a result, accessinguninitialized memory is possible. Actually, adding multiple DAMOS filtersvia DAMON sysfs interface caused NULL pointer dereferencing. Initializethe field just after the allocation from damos_new_filter().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix use-after-free in free_netdevWe do netif_napi_add() for all allocated q_vectors[], but potentiallydo netif_napi_del() for part of them, then kfree q_vectors and leaveinvalid pointers at dev->napi_list.Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) waitResult:[ 4093.900222] ==================================================================[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699[ 4093.900233][ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021[ 4093.900239] Call Trace:[ 4093.900244] dump_stack+0x71/0xab[ 4093.900249] print_address_description+0x6b/0x290[ 4093.900251] ? free_netdev+0x308/0x390[ 4093.900252] kasan_report+0x14a/0x2b0[ 4093.900254] free_netdev+0x308/0x390[ 4093.900261] iavf_remove+0x825/0xd20 [iavf][ 4093.900265] pci_device_remove+0xa8/0x1f0[ 4093.900268] device_release_driver_internal+0x1c6/0x460[ 4093.900271] pci_stop_bus_device+0x101/0x150[ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20[ 4093.900275] pci_iov_remove_virtfn+0x187/0x420[ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10[ 4093.900278] ? pci_get_subsys+0x90/0x90[ 4093.900280] sriov_disable+0xed/0x3e0[ 4093.900282] ? bus_find_device+0x12d/0x1a0[ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e][ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e][ 4093.900299] ? pci_get_device+0x7c/0x90[ 4093.900300] ? pci_get_subsys+0x90/0x90[ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210[ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e][ 4093.900318] sriov_numvfs_store+0x214/0x290[ 4093.900320] ? sriov_totalvfs_show+0x30/0x30[ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900323] ? __check_object_size+0x15a/0x350[ 4093.900326] kernfs_fop_write+0x280/0x3f0[ 4093.900329] vfs_write+0x145/0x440[ 4093.900330] ksys_write+0xab/0x160[ 4093.900332] ? __ia32_sys_read+0xb0/0xb0[ 4093.900334] ? fput_many+0x1a/0x120[ 4093.900335] ? filp_close+0xf0/0x130[ 4093.900338] do_syscall_64+0xa0/0x370[ 4093.900339] ? page_fault+0x8/0x30[ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 4093.900357] RIP: 0033:0x7f16ad4d22c0[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700[ 4093.9003---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fprobe: Release rethook after the ftrace_ops is unregisteredWhile running bpf selftests it's possible to get following fault: general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI ... Call Trace: fprobe_handler+0xc1/0x270 ? __pfx_bpf_testmod_init+0x10/0x10 ? __pfx_bpf_testmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initcall+0x63/0x2e0 ? rcu_is_watching+0xd/0x40 ? kmalloc_trace+0xaf/0xc0 ? do_init_module+0x60/0x250 ? __do_sys_finit_module+0xac/0x120 ? do_syscall_64+0x37/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc In unregister_fprobe function we can't release fp->rethook while it'spossible there are some of its users still running on another cpu.Moving rethook_free call after fp->ops is unregistered withunregister_ftrace_function call.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()pr_info() is called with rtp->cbs_gbl_lock spin lock locked. Becausepr_info() calls printk() that might sleep, this will result in BUGlike below:[ 0.206455] cblist_init_generic: Setting adjustable number of callback queues.[ 0.206463][ 0.206464] =============================[ 0.206464] [ BUG: Invalid wait context ][ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted[ 0.206466] -----------------------------[ 0.206466] swapper/0/1 is trying to lock:[ 0.206467] ffffffffa0167a58 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0[ 0.206473] other info that might help us debug this:[ 0.206473] context-{5:5}[ 0.206474] 3 locks held by swapper/0/1:[ 0.206474] #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0[ 0.206478] #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e[ 0.206482] #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330[ 0.206485] stack backtrace:[ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5[ 0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014[ 0.206489] Call Trace:[ 0.206490] [ 0.206491] dump_stack_lvl+0x6a/0x9f[ 0.206493] __lock_acquire.cold+0x2d7/0x2fe[ 0.206496] ? stack_trace_save+0x46/0x70[ 0.206497] lock_acquire+0xd1/0x2f0[ 0.206499] ? serial8250_console_write+0x327/0x4a0[ 0.206500] ? __lock_acquire+0x5c7/0x2720[ 0.206502] _raw_spin_lock_irqsave+0x3d/0x90[ 0.206504] ? serial8250_console_write+0x327/0x4a0[ 0.206506] serial8250_console_write+0x327/0x4a0[ 0.206508] console_emit_next_record.constprop.0+0x180/0x330[ 0.206511] console_unlock+0xf7/0x1f0[ 0.206512] vprintk_emit+0xf7/0x330[ 0.206514] _printk+0x63/0x7e[ 0.206516] cblist_init_generic.constprop.0.cold+0x24/0x32[ 0.206518] rcu_init_tasks_generic+0x5/0xd9[ 0.206522] kernel_init_freeable+0x15b/0x2a2[ 0.206523] ? rest_init+0x160/0x160[ 0.206526] kernel_init+0x11/0x120[ 0.206527] ret_from_fork+0x1f/0x30[ 0.206530] [ 0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.This patch moves pr_info() so that it is called withoutrtp->cbs_gbl_lock locked.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip_vti: fix potential slab-use-after-free in decode_session6When ip_vti device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when ip_vti device sends IPv6 packets.As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing/histograms: Add histograms to hist_vars if they have referenced variablesHist triggers can have referenced variables without having directvariables fields. This can be the case if referenced variables are addedfor trigger actions. In this case the newly added references will nothave field variables. Not taking such referenced variables intoconsideration can result in a bug where it would be possible to removehist trigger with variables being refenced. This will result in a bugthat is easily reproducable like so$ cd /sys/kernel/tracing$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger[ 100.263533] ==================================================================[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439[ 100.266320][ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014[ 100.268561] Call Trace:[ 100.268902] [ 100.269189] dump_stack_lvl+0x4c/0x70[ 100.269680] print_report+0xc5/0x600[ 100.270165] ? resolve_var_refs+0xc7/0x180[ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0[ 100.271389] ? resolve_var_refs+0xc7/0x180[ 100.271913] kasan_report+0xbd/0x100[ 100.272380] ? resolve_var_refs+0xc7/0x180[ 100.272920] __asan_load8+0x71/0xa0[ 100.273377] resolve_var_refs+0xc7/0x180[ 100.273888] event_hist_trigger+0x749/0x860[ 100.274505] ? kasan_save_stack+0x2a/0x50[ 100.275024] ? kasan_set_track+0x29/0x40[ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10[ 100.276138] ? ksys_write+0xd1/0x170[ 100.276607] ? do_syscall_64+0x3c/0x90[ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 100.277771] ? destroy_hist_data+0x446/0x470[ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860[ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10[ 100.279627] ? __kasan_check_write+0x18/0x20[ 100.280177] ? mutex_unlock+0x85/0xd0[ 100.280660] ? __pfx_mutex_unlock+0x10/0x10[ 100.281200] ? kfree+0x7b/0x120[ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0[ 100.282197] ? event_trigger_write+0xac/0x100[ 100.282764] ? __kasan_slab_free+0x16/0x20[ 100.283293] ? __kmem_cache_free+0x153/0x2f0[ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250[ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10[ 100.285221] ? event_trigger_write+0xbc/0x100[ 100.285781] ? __kasan_check_read+0x15/0x20[ 100.286321] ? __bitmap_weight+0x66/0xa0[ 100.286833] ? _find_next_bit+0x46/0xe0[ 100.287334] ? task_mm_cid_work+0x37f/0x450[ 100.287872] event_triggers_call+0x84/0x150[ 100.288408] trace_event_buffer_commit+0x339/0x430[ 100.289073] ? ring_buffer_event_data+0x3f/0x60[ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0[ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0[ 100.298653] syscall_enter_from_user_mode+0x32/0x40[ 100.301808] do_syscall_64+0x1a/0x90[ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 100.307775] RIP: 0033:0x7f686c75c1cb[ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48[ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021[ 100.321200] RA---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: amd-pstate-ut: Fix kernel panic when loading the driverAfter loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policyof the CPU and mark it as busy.In these functions, cpufreq_cpu_put() should be used to release thepolicy, but it is not, so any other entity trying to access the policyis blocked indefinitely.One such scenario is when amd_pstate mode is changed, leading to thefollowing splat:[ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.[ 1332.110001] Not tainted 6.5.0-rc2-amd-pstate-ut #5[ 1332.115315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 1332.123140] task:bash state:D stack:0 pid:2929 ppid:2873 flags:0x00004006[ 1332.123143] Call Trace:[ 1332.123145] [ 1332.123148] __schedule+0x3c1/0x16a0[ 1332.123154] ? _raw_read_lock_irqsave+0x2d/0x70[ 1332.123157] schedule+0x6f/0x110[ 1332.123160] schedule_timeout+0x14f/0x160[ 1332.123162] ? preempt_count_add+0x86/0xd0[ 1332.123165] __wait_for_common+0x92/0x190[ 1332.123168] ? __pfx_schedule_timeout+0x10/0x10[ 1332.123170] wait_for_completion+0x28/0x30[ 1332.123173] cpufreq_policy_put_kobj+0x4d/0x90[ 1332.123177] cpufreq_policy_free+0x157/0x1d0[ 1332.123178] ? preempt_count_add+0x58/0xd0[ 1332.123180] cpufreq_remove_dev+0xb6/0x100[ 1332.123182] subsys_interface_unregister+0x114/0x120[ 1332.123185] ? preempt_count_add+0x58/0xd0[ 1332.123187] ? __pfx_amd_pstate_change_driver_mode+0x10/0x10[ 1332.123190] cpufreq_unregister_driver+0x3b/0xd0[ 1332.123192] amd_pstate_change_driver_mode+0x1e/0x50[ 1332.123194] store_status+0xe9/0x180[ 1332.123197] dev_attr_store+0x1b/0x30[ 1332.123199] sysfs_kf_write+0x42/0x50[ 1332.123202] kernfs_fop_write_iter+0x143/0x1d0[ 1332.123204] vfs_write+0x2df/0x400[ 1332.123208] ksys_write+0x6b/0xf0[ 1332.123210] __x64_sys_write+0x1d/0x30[ 1332.123213] do_syscall_64+0x60/0x90[ 1332.123216] ? fpregs_assert_state_consistent+0x2e/0x50[ 1332.123219] ? exit_to_user_mode_prepare+0x49/0x1a0[ 1332.123223] ? irqentry_exit_to_user_mode+0xd/0x20[ 1332.123225] ? irqentry_exit+0x3f/0x50[ 1332.123226] ? exc_page_fault+0x8e/0x190[ 1332.123228] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 1332.123232] RIP: 0033:0x7fa74c514a37[ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37[ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001[ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff[ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008[ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00[ 1332.123247] Fix this by calling cpufreq_cpu_put() wherever necessary.[ rjw: Subject and changelog edits ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: don't leak memory if dev_set_name() failsWhen dev_set_name() fails, zcdn_create() doesn't free the newlyallocated resources. Do it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count thenumber of MBSSID elements in the nested netlink attribute attrs, which canlead to an integer overflow if a user of the nl80211 interface specifies256 or more elements in the corresponding attribute in userspace. Theinteger overflow can lead to a heap buffer overflow as num_elems determinesthe size of the trailing array in elems, and this array is thereafterwritten to for each element in attrs.Note that this vulnerability only affects devices with thewiphy->mbssid_max_interfaces member set for the wireless physical devicestruct in the device driver, and can only be triggered by a process withCAP_NET_ADMIN capabilities.Fix this by checking for a maximum of 255 elements in attrs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: scu: use _safe list iterator to avoid a use after freeThis loop is freeing "clk" so it needs to use list_for_each_entry_safe().Otherwise it dereferences a freed variable to get the next item on theloop.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, cpumap: Make sure kthread is running before map update returnsThe following warning was reported when running stress-mode enabledxdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memoryleak in cpu_map_update_elem"). The kthread is stopped prematurely bykthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't callcpu_map_kthread_run() at all but XDP program has already queued someframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checksthe ptr_ring, it will find it was not emptied and report a warning.An alternative fix is to use __cpu_map_ring_cleanup() to drop thesepending frames or skbs when kthread_stop() returns -EINTR, but it mayconfuse the user, because these frames or skbs have been handledcorrectly by XDP program. So instead of dropping these frames or skbs,just make sure the per-cpu kthread is running before__cpu_map_entry_alloc() returns.After apply the fix, the error handle for kthread_stop() will beunnecessary because it will always return 0, so just remove it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: mvebu: fix irq domain leakUwe Kleine-K?nig pointed out we still have one resource leak in the mvebudriver triggered on driver detach. Let's address it with a custom devmaction.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: Gadget: core: Help prevent panic during UVC unconfigureAvichal Rakesh reported a kernel panic that occurred when the UVCgadget driver was removed from a gadget's configuration. The panicinvolves a somewhat complicated interaction between the kernel driverand a userspace component (as described in the Link tag below), butthe analysis did make one thing clear: The Gadget core shouldaccomodate gadget drivers calling usb_gadget_deactivate() as part oftheir unbind procedure.Currently this doesn't work. gadget_unbind_driver() callsdriver->unbind() while holding the udc->connect_lock mutex, andusb_gadget_deactivate() attempts to acquire that mutex, which willresult in a deadlock.The simple fix is for gadget_unbind_driver() to release the mutex wheninvoking the ->unbind() callback. There is no particular reason forit to be holding the mutex at that time, and the mutex isn't heldwhile the ->bind() callback is invoked. So we'll drop the mutexbefore performing the unbind callback and reacquire it afterward.We'll also add a couple of comments to usb_gadget_activate() andusb_gadget_deactivate(). Because they run in process context theymust not be called from a gadget driver's ->disconnect() callback,which (according to the kerneldoc for struct usb_gadget_driver ininclude/linux/usb/gadget.h) may run in interrupt context. This mayhelp prevent similar bugs from arising in the future.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Release folio lock on fscache read hit.Under the current code, when cifs_readpage_worker is called, the callcontract is that the callee should unlock the page. This is documentedin the read_folio section of Documentation/filesystems/vfs.rst as:> The filesystem should unlock the folio once the read has completed,> whether it was successful or not.Without this change, when fscache is in use and cache hit occurs duringa read, the page lock is leaked, producing the following stack onsubsequent reads (via mmap) to the page:$ cat /proc/3890/task/12864/stack[<0>] folio_wait_bit_common+0x124/0x350[<0>] filemap_read_folio+0xad/0xf0[<0>] filemap_fault+0x8b1/0xab0[<0>] __do_fault+0x39/0x150[<0>] do_fault+0x25c/0x3e0[<0>] __handle_mm_fault+0x6ca/0xc70[<0>] handle_mm_fault+0xe9/0x350[<0>] do_user_addr_fault+0x225/0x6c0[<0>] exc_page_fault+0x84/0x1b0[<0>] asm_exc_page_fault+0x27/0x30This requires a reboot to resolve; it is a deadlock.Note however that the call to cifs_readpage_from_fscache does mark thepage clean, but does not free the folio lock. This happens in__cifs_readpage_from_fscache on success. Releasing the lock at thatpoint however is not appropriate as cifs_readahead also callscifs_readpage_from_fscache and *does* unconditionally release the lockafter its return. This change therefore effectively makescifs_readpage_worker work like cifs_readahead.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: base: Free devm resources when unregistering a deviceIn the current code, devres_release_all() only gets called if the devicehas a bus and has been probed.This leads to issues when using bus-less or driver-less devices wherethe device might never get freed if a managed resource holds a referenceto the device. This is happening in the DRM framework for example.We should thus call devres_release_all() in the device_del() function tomake sure that the device-managed actions are properly executed when thedevice is unregistered, even if it has neither a bus nor a driver.This is effectively the same change than commit 2f8d16a996da ("devres:release resources on device_del()") that got reverted by commita525a3ddeaca ("driver core: free devres in device_release") overmemory leaks concerns.This patch effectively combines the two commits mentioned above torelease the resources both on device_del() and device_release() and getthe best of both worlds.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix mid leak during reconnection after timeout thresholdWhen the number of responses with status of STATUS_IO_TIMEOUTexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnectthe connection. But we do not return the mid, or the creditsreturned for the mid, or reduce the number of in-flight requests.This bug could result in the server->in_flight count to go bad,and also cause a leak in the mids.This change moves the check to a few lines below where theresponse is decrypted, even of the response is read from thetransform header. This way, the code for returning the midscan be reused.Also, the cifs_reconnect was reconnecting just the transportconnection before. In case of multi-channel, this may not bewhat we want to do after several timeouts. Changed that toreconnect the session and the tree too.Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate nameMAX_STATUS_IO_TIMEOUT.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to pointto the scatterlist array in areq->first_rsgl.sgl.sgl.Without this, the gcm-aes-s390 driver will oops when it tries to dogcm_walk_start() on req->dst because req->dst is set to the value ofareq->first_rsgl.sgl.sgl by _aead_recvmsg() callingaead_request_set_crypt().The problem comes if an empty ciphertext is passed: the loop inaf_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsglup.This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as faras I can tell, that ignores req->dst and only uses req->src[*].[*] Is this a bug in aesni-intel_glue.c?The s390x oops looks something like: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000a00000000 TEID: 0000000a00000803 Fault in home space mode while using kernel ASCE. AS:00000000a43a0007 R3:0000000000000024 Oops: 003b ilc:2 [#1] SMP ... Call Trace: [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390] [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8 [<00000000a2a60888>] aead_recvmsg+0x478/0x698 [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0 [<00000000a2e51a56>] sock_read_iter+0x76/0xa0 [<00000000a273e066>] vfs_read+0x26e/0x2a8 [<00000000a273e8c4>] ksys_read+0xbc/0x100 [<00000000a311d808>] __do_syscall+0x1d0/0x1f8 [<00000000a312ff30>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tunnels: fix kasan splat when generating ipv4 pmtu errorIf we try to emit an icmp error in response to a nonliner skb, we getBUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220Read of size 4 at addr ffff88811c50db00 by task iperf3/1691CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309[..] kasan_report+0x105/0x140 ip_compute_csum+0x134/0x220 iptunnel_pmtud_build_icmp+0x554/0x1020 skb_tunnel_check_pmtu+0x513/0xb80 vxlan_xmit_one+0x139e/0x2ef0 vxlan_xmit+0x1867/0x2760 dev_hard_start_xmit+0x1ee/0x4f0 br_dev_queue_push_xmit+0x4d1/0x660 [..]ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.After this change, splat is gone and iperf3 is no longer stuck.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: do not assume skb mac_header is setDrivers must not assume in their ndo_start_xmit() thatskbs have their mac_header set. skb->data is all what is needed.bonding seems to be one of the last offender as caught by syzbot:WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470Modules linked in:CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e feRSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7eR13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380[] dev_direct_xmit include/linux/netdevice.h:3043 [inline][] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284[] packet_snd net/packet/af_packet.c:3112 [inline][] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Avoid fcport pointer dereferenceKlocwork reported warning of NULL pointer may be dereferenced. The routineexits when sa_ctl is NULL and fcport is allocated after the exit call thuscausing NULL fcport pointer to dereference at the time of exit.To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi_si: fix a memleak in try_smi_init()Kmemleak reported the following leak info in try_smi_init():unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180The problem was that when an error occurred before handlers registrationand after allocating `new_smi->si_sm`, the variable wouldn't be freed inthe error handling afterwards since `shutdown_smi()` hadn't beenregistered yet. Fix it by adding a `kfree()` in the error handling pathin `try_smi_init()`.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dax: Fix dax_mapping_release() use after freeA CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax regionprovider (like modprobe -r dax_hmem) yields: kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000) [..] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: [..] lock_acquire+0xd4/0x2c0 ? ida_free+0x62/0x130 _raw_spin_lock_irqsave+0x47/0x70 ? ida_free+0x62/0x130 ida_free+0x62/0x130 dax_mapping_release+0x1f/0x30 device_release+0x36/0x90 kobject_delayed_cleanup+0x46/0x150Due to attempting ida_free() on an ida object that has already beenfreed. Devices typically only hold a reference on their parent whileregistered. If a child needs a parent object to complete its release itneeds to hold a reference that it drops from its release callback.Arrange for a dax_mapping to pin its parent dev_dax instance untildax_mapping_release().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix deletion race conditionSystem crash when using debug kernel due to link list corruption. The causeof the link list corruption is due to session deletion was allowed to queueup twice. Here's the internal trace that show the same port was allowed todouble queue for deletion on different cpu.20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 120808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1Move the clearing/setting of deleted flag lock.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: socinfo: Add kfree for kstrdupAdd kfree() in the later error handling in order to avoid memory leak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject invalid reloc tree root keys with stack dump[BUG]Syzbot reported a crash that an ASSERT() got triggered insideprepare_to_merge().That ASSERT() makes sure the reloc tree is properly pointed back by itssubvolume tree.[CAUSE]After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.But reloc trees can only exist for subvolumes, as for non-subvolumetrees, we just COW the involved tree block, no need to create a reloctree since those tree blocks won't be shared with other trees.Only subvolumes tree can share tree blocks with other trees (thus theyhave BTRFS_ROOT_SHAREABLE flag).Thus this new debug output proves my previous assumption that corruptedon-disk data can trigger that ASSERT().[FIX]Besides the dedicated fix and the graceful exit, also let tree-checker tocheck such root keys, to make sure reloc trees can only exist for subvolumes.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memcontrol: ensure memcg acquired by id is properly set upIn the eviction recency check, we attempt to retrieve the memcg to whichthe folio belonged when it was evicted, by the memcg id stored in theshadow entry. However, there is a chance that the retrieved memcg is notthe original memcg that has been killed, but a new one which happens tohave the same id.This is a somewhat unfortunate, but acceptable and rare inaccuracy in theheuristics. However, if we retrieve this new memcg between its allocationand when it is properly attached to the memcg hierarchy, we could run intothe following NULL pointer exception during the memcg hierarchy traversaldone in mem_cgroup_get_nr_swap_pages():[ 155757.793456] BUG: kernel NULL pointer dereference, address: 00000000000000c0[ 155757.807568] #PF: supervisor read access in kernel mode[ 155757.818024] #PF: error_code(0x0000) - not-present page[ 155757.828482] PGD 401f77067 P4D 401f77067 PUD 401f76067 PMD 0[ 155757.839985] Oops: 0000 [#1] SMP[ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swap_pages+0x3d/0xb0[ 155757.899377] Code: 29 19 4a 02 48 39 f9 74 63 48 8b 97 c0 00 00 00 48 8b b7 58 02 00 00 48 2b b7 c0 01 00 00 48 39 f0 48 0f 4d c6 48 39 d1 74 42 <48> 8b b2 c0 00 00 00 48 8b ba 58 02 00 00 48 2b ba c0 01 00 00 48[ 155757.937125] RSP: 0018:ffffc9002ecdfbc8 EFLAGS: 00010286[ 155757.947755] RAX: 00000000003a3b1c RBX: 000007ffffffffff RCX: ffff888280183000[ 155757.962202] RDX: 0000000000000000 RSI: 0007ffffffffffff RDI: ffff888bbc2d1000[ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0[ 155757.991094] R10: ffffea0039c07900 R11: 0000000000000010 R12: ffff888b23a7b000[ 155758.005540] R13: 0000000000000000 R14: ffff888bbc2d1000 R15: 000007ffffc71354[ 155758.019991] FS: 00007f6234c68640(0000) GS:ffff88903f9c0000(0000) knlGS:0000000000000000[ 155758.036356] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 155758.048023] CR2: 00000000000000c0 CR3: 0000000a83eb8004 CR4: 00000000007706e0[ 155758.062473] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 155758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 155758.091376] PKRU: 55555554[ 155758.096957] Call Trace:[ 155758.102016] [ 155758.106502] ? __die+0x78/0xc0[ 155758.112793] ? page_fault_oops+0x286/0x380[ 155758.121175] ? exc_page_fault+0x5d/0x110[ 155758.129209] ? asm_exc_page_fault+0x22/0x30[ 155758.137763] ? mem_cgroup_get_nr_swap_pages+0x3d/0xb0[ 155758.148060] workingset_test_recent+0xda/0x1b0[ 155758.157133] workingset_refault+0xca/0x1e0[ 155758.165508] filemap_add_folio+0x4d/0x70[ 155758.173538] page_cache_ra_unbounded+0xed/0x190[ 155758.182919] page_cache_sync_ra+0xd6/0x1e0[ 155758.191738] filemap_read+0x68d/0xdf0[ 155758.199495] ? mlx5e_napi_poll+0x123/0x940[ 155758.207981] ? __napi_schedule+0x55/0x90[ 155758.216095] __x64_sys_pread64+0x1d6/0x2c0[ 155758.224601] do_syscall_64+0x3d/0x80[ 155758.232058] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 155758.242473] RIP: 0033:0x7f62c29153b5[ 155758.249938] Code: e8 48 89 75 f0 89 7d f8 48 89 4d e0 e8 b4 e6 f7 ff 41 89 c0 4c 8b 55 e0 48 8b 55 e8 48 8b 75 f0 8b 7d f8 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 45 f8 e8 e7 e6 f7 ff 48 8b[ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011[ 155758.303474] RAX: ffffffffffffffda RBX: 00007f628c4e70c0 RCX: 00007f62c29153b5[ 155758.318075] RDX: 000000000003c041 RSI: 00007f61d2986000 RDI: 0000000000000076[ 155758.332678] RBP: 00007f6234c5fff0 R08: 0000000000000000 R09: 0000000064d5230c[ 155758.347452] R10: 000000000027d450 R11: 0000000000000293 R12: 000000000003c041[ 155758.362044] R13: 00007f61d2986000 R14: 00007f629e11b060 R15: 000000000027d450[ 155758.376661] This patch fixes the issue by moving the memcg's id publication from thealloc stage to ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-sysman: Fix reference leakIf a duplicate attribute is found using kset_find_obj(),a reference to that attribute is returned. This meansthat we need to dispose it accordingly. Use kobject_put()to dispose the duplicate attribute in such a case.Compile-tested only.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Take RTNL lock when needed before calling xdp_set_features()Hold RTNL lock when calling xdp_set_features() with a registered netdev,as the call triggers the netdev notifiers. This could happen whenswitching from uplink rep to nic profile for example.This resolves the following call trace:RTNL: assertion failed at net/core/dev.c (1953)WARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80Modules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]CPU: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:call_netdevice_notifiers_info+0x7c/0x80Code: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff <0f> 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ecRSP: 0018:ffff8882a21c3948 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027RDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0RBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003R10: ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968R13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0FS: 00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn+0x79/0x120 ? call_netdevice_notifiers_info+0x7c/0x80 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? call_netdevice_notifiers_info+0x7c/0x80 ? call_netdevice_notifiers_info+0x7c/0x80 call_netdevice_notifiers+0x2e/0x50 mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core] mlx5e_nic_init+0xf1/0x1a0 [mlx5_core] mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core] mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core] mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core] mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core] __esw_offloads_unload_rep+0x52/0x60 [mlx5_core] mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core] esw_offloads_unload_rep+0x34/0x70 [mlx5_core] esw_offloads_disable+0x2b/0x90 [mlx5_core] mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core] mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core] ? devlink_get_from_attrs_lock+0x9e/0x110 devlink_nl_cmd_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x17d/0x2b0 ? devlink_get_from_attrs_lock+0x110/0x110 ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290 ? devlink_pernet_pre_exit+0xf0/0xf0 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x232/0x4a0 sock_sendmsg+0x38/0x60 ? _copy_from_user+0x2a/0x60 __sys_sendto+0x110/0x160 ? __count_memcg_events+0x48/0x90 ? handle_mm_fault+0x161/0x260 ? do_user_addr_fault+0x278/0x6e0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: cancel queued works in probe error pathIf it fails to get the devices's MAC address, octep_probe exits whileleaving the delayed work intr_poll_task queued. When the work laterruns, it's a use after free.Move the cancelation of intr_poll_task from octep_remove intooctep_device_cleanup. This does not change anything in the octep_removeflow, but octep_device_cleanup is called also in the octep_probe errorpath, where the cancelation is needed.Note that the cancelation of ctrl_mbox_task has to followintr_poll_task's, because the ctrl_mbox_task may be queued byintr_poll_task.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make bpf_refcount_acquire fallible for non-owning refsThis patch fixes an incorrect assumption made in the originalbpf_refcount series [0], specifically that the BPF program callingbpf_refcount_acquire on some node can always guarantee that the node isalive. In that series, the patch adding failure behavior to rbtree_addand list_push_{front, back} breaks this assumption for non-owningreferences.Consider the following program: n = bpf_kptr_xchg(&mapval, NULL); /* skip error checking */ bpf_spin_lock(&l); if(bpf_rbtree_add(&t, &n->rb, less)) { bpf_refcount_acquire(n); /* Failed to add, do something else with the node */ } bpf_spin_unlock(&l);It's incorrect to assume that bpf_refcount_acquire will always succeed in thisscenario. bpf_refcount_acquire is being called in a critical sectionhere, but the lock being held is associated with rbtree t, which isn'tnecessarily the lock associated with the tree that the node is alreadyin. So after bpf_rbtree_add fails to add the node and calls bpf_obj_dropin it, the program has no ownership of the node's lifetime. Thereforethe node's refcount can be decr'd to 0 at any time after the failingrbtree_add. If this happens before the refcount_acquire above, the nodemight be free'd, and regardless refcount_acquire will be incrementing a0 refcount.Later patches in the series exercise this scenario, resulting in theexpected complaint from the kernel (without this patch's changes): refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110 Modules linked in: bpf_testmod(O) CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0xbc/0x110 Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff <0f> 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7 RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680 RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7 R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388 R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048 FS: 00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: bpf_refcount_acquire_impl+0xb5/0xc0 (rest of output snipped)The patch addresses this by changing bpf_refcount_acquire_impl to userefcount_inc_not_zero instead of refcount_inc and markingbpf_refcount_acquire KF_RET_NULL.For owning references, though, we know the above scenario is not possibleand thus that bpf_refcount_acquire will always succeed. Some verifierbookkeeping is added to track "is input owning ref?" for bpf_refcount_acquirecalls and return false from is_kfunc_ret_null for bpf_refcount_acquire onowning refs despite it being marked KF_RET_NULL.Existing selftests using bpf_refcount_acquire are modified wherenecessary to NULL-check its return value. [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/perf: add sentinel to xehp_oa_b_countersArrays passed to reg_in_range_table should end with empty record.The patch solves KASAN detected bug with signature:BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]Read of size 4 at addr ffffffffa1555d90 by task perf/1518CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023Call Trace:...xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915](cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't dereference ACPI root object handleSince the commit referenced in the Fixes: tag below the VMBus client driveris walking the ACPI namespace up from the VMBus ACPI device to the ACPInamespace root object trying to find Hyper-V MMIO ranges.However, if it is not able to find them it ends trying to walk resources ofthe ACPI namespace root object itself.This object has all-ones handle, which causes a NULL pointer dereferencein the ACPI code (from dereferencing this pointer with an offset).This in turn causes an oops on boot with VMBus host implementations that donot provide Hyper-V MMIO ranges in their VMBus ACPI device or itsancestors.The QEMU VMBus implementation is an example of such implementation.I guess providing these ranges is optional, since all tested Windowsversions seem to be able to use VMBus devices without them.Fix this by explicitly terminating the lookup at the ACPI namespace rootobject.Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interfaceby default - they only do so if the KVM PV interface is missing ordisabled.Example stack trace of such oops:[ 3.710827] ? __die+0x1f/0x60[ 3.715030] ? page_fault_oops+0x159/0x460[ 3.716008] ? exc_page_fault+0x73/0x170[ 3.716959] ? asm_exc_page_fault+0x22/0x30[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0[ 3.723559] ? down_timeout+0x3a/0x60[ 3.724455] ? acpi_ns_get_node+0x3a/0x60[ 3.725412] acpi_ns_get_node+0x3a/0x60[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0[ 3.728400] acpi_rs_get_method_data+0x2b/0x70[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.732411] acpi_walk_resources+0x78/0xd0[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus][ 3.734802] platform_probe+0x3d/0x90[ 3.735684] really_probe+0x19b/0x400[ 3.736570] ? __device_attach_driver+0x100/0x100[ 3.737697] __driver_probe_device+0x78/0x160[ 3.738746] driver_probe_device+0x1f/0x90[ 3.739743] __driver_attach+0xc2/0x1b0[ 3.740671] bus_for_each_dev+0x70/0xc0[ 3.741601] bus_add_driver+0x10e/0x210[ 3.742527] driver_register+0x55/0xf0[ 3.744412] ? 0xffffffffc039a000[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixersmatch error:sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:we previously assumed 'rac97' could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add features 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 features attr to avoidsuch bugs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: amphion: fix REVERSE_INULL issues reported by coveritynull-checking of a pointor is suggested before dereferencing it
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't tx before switchdev is fully configuredThere is possibility that ice_eswitch_port_start_xmit might becalled while some resources are still not allocated which mightcause NULL pointer dereference. Fix this by checking if switchdevconfiguration was finished.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: bcm-qspi: return error if neither hif_mspi nor mspi is availableIf neither a "hif_mspi" nor "mspi" resource is present, the driver willjust early exit in probe but still return success. Apart from not doinganything meaningful, this would then also lead to a null pointer accesson removal, as platform_get_drvdata() would return NULL, which it wouldthen try to dereference when trying to unregister the spi master.Fix this by unconditionally calling devm_ioremap_resource(), as it canhandle a NULL res and will then return a viable ERR_PTR() if we get one.The "return 0;" was previously a "goto qspi_resource_err;" where thenret was returned, but since ret was still initialized to 0 at this placethis was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fixuse-after-free on unbind"). The issue was not introduced by this commit,only made more obvious.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, cpumap: Handle skb as well when clean up ptr_ringThe following warning was reported when running xdp_redirect_cpu withboth skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150 __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 The reason for the warning is twofold. One is due to the kthreadcpu_map_kthread_run() is stopped prematurely. Another one is__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs inptr_ring as XDP frames.Prematurely-stopped kthread will be fixed by the preceding patch andptr_ring will be empty when __cpu_map_ring_cleanup() is called. Butas the comments in __cpu_map_ring_cleanup() said, handling and freeingskbs in ptr_ring as well to "catch any broken behaviour gracefully".
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd938x: fix missing mbhc init error handlingMBHC initialisation can fail so add the missing error handling to avoiddereferencing an error pointer when later configuring the jack: Unable to handle kernel paging request at virtual address fffffffffffffff8 pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc] lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x] Call trace: wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc] wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x] snd_soc_component_set_jack+0x28/0x8c [snd_soc_core] qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common] sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp] snd_soc_link_init+0x28/0x90 [snd_soc_core] snd_soc_bind_card+0x628/0xbfc [snd_soc_core] snd_soc_register_card+0xec/0x104 [snd_soc_core] devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core] sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: fix null-ptr-deref in handshake_nl_done_doit()We should not call trace_handshake_cmd_done_err() if socket lookup has failed.Also we should call trace_handshake_cmd_done_err() before releasing the file,otherwise dereferencing sock->sk can return garbage.This also reverts 7afc6d0a107f ("net/handshake: Fix uninitialized local variable")Unable to handle kernel paging request at virtual address dfff800000000003KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]Mem abort info:ESR = 0x0000000096000005EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x05: level 1 translation faultData abort info:ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[dfff800000000003] address between user and kernel address rangesInternal error: Oops: 0000000096000005 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193lr : handshake_nl_done_doit+0x180/0x9c8sp : ffff800096e37180x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000x20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000Call trace:handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914sock_sendmsg_nosec net/socket.c:725 [inline]sock_sendmsg net/socket.c:748 [inline]____sys_sendmsg+0x56c/0x840 net/socket.c:2494___sys_sendmsg net/socket.c:2548 [inline]__sys_sendmsg+0x26c/0x33c net/socket.c:2577__do_sys_sendmsg net/socket.c:2586 [inline]__se_sys_sendmsg net/socket.c:2584 [inline]__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: Fix the memory leak in raw_gadget driverCurrently, increasing raw_dev->count happens before invoke theraw_queue_event(), if the raw_queue_event() return error, invokeraw_release() will not trigger the dev_free() to be called.[ 268.905865][ T5067] raw-gadget.0 gadget.0: failed to queue event[ 268.912053][ T5067] udc dummy_udc.0: failed to start USB Raw Gadget: -12[ 268.918885][ T5067] raw-gadget.0: probe of gadget.0 failed with error -12[ 268.925956][ T5067] UDC core: USB Raw Gadget: couldn't find an available UDC or it's busy[ 268.934657][ T5067] misc raw-gadget: fail, usb_gadget_register_driver returned -16BUG: memory leak[] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] kzalloc include/linux/slab.h:703 [inline][] dev_new drivers/usb/gadget/legacy/raw_gadget.c:191 [inline][] raw_open+0x45/0x110 drivers/usb/gadget/legacy/raw_gadget.c:385[] misc_open+0x1a9/0x1f0 drivers/char/misc.c:165[] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] raw_ioctl_init+0xdf/0x410 drivers/usb/gadget/legacy/raw_gadget.c:460[] raw_ioctl+0x5f9/0x1120 drivers/usb/gadget/legacy/raw_gadget.c:1250[] vfs_ioctl fs/ioctl.c:51 [inline][] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] kzalloc include/linux/slab.h:703 [inline][] dummy_alloc_request+0x5a/0xe0 drivers/usb/gadget/udc/dummy_hcd.c:665[] usb_ep_alloc_request+0x22/0xd0 drivers/usb/gadget/udc/core.c:196[] gadget_bind+0x6d/0x370 drivers/usb/gadget/legacy/raw_gadget.c:292This commit therefore invoke kref_get() under the condition thatraw_queue_event() return success.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1The type of size is unsigned int, if size is 0x40000000, there willbe an integer overflow, size will be zero after size *= sizeof(uint32_t),will cause uninitialized memory to be referenced later.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: csum: Fix OoB access in IP checksum code for negative lengthsAlthough commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-lengthcalls") added an early return for zero-length input, syzkaller haspopped up with an example of a _negative_ length which causes anundefined shift and an out-of-bounds read: | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975 | | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 | Call trace: | dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 | show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 | __dump_stack lib/dump_stack.c:88 [inline] | dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 | print_address_description mm/kasan/report.c:351 [inline] | print_report+0x174/0x514 mm/kasan/report.c:462 | kasan_report+0xd4/0x130 mm/kasan/report.c:572 | kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 | __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31 | do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | csum_partial+0x30/0x58 lib/checksum.c:128 | gso_make_checksum include/linux/skbuff.h:4928 [inline] | __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332 | udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47 | ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119 | skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141 | __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401 | skb_gso_segment include/linux/netdevice.h:4859 [inline] | validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659 | validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709 | sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327 | __dev_xmit_skb net/core/dev.c:3805 [inline] | __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210 | dev_queue_xmit include/linux/netdevice.h:3085 [inline] | packet_xmit+0x6c/0x318 net/packet/af_packet.c:276 | packet_snd net/packet/af_packet.c:3081 [inline] | packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113 | sock_sendmsg_nosec net/socket.c:724 [inline] | sock_sendmsg net/socket.c:747 [inline] | __sys_sendto+0x3b4/0x538 net/socket.c:2144Extend the early return to reject negative lengths as well, aligning ourimplementation with the generic code in lib/checksum.c
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: avoid stalls in fq_pie_timer()When setting a high number of flows (limit being 65536),fq_pie_timer() is currently using too much time as syzbot reported.Add logic to yield the cpu every 2048 flows (less than 150 usecon debug kernels).It should also help by not blocking qdisc fast paths for too long.Worst case (65536 flows) would need 31 jiffies for a complete scan.Relevant extract from syzbot report:rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.rcu: blocking rcu_node structures (internal RCU debug):Sending NMI from CPU 1 to CPUs 0:NMI backtrace for cpu 0CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00
00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8bRSP: 0018:ffffc90000007bb8 EFLAGS: 00000206RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;"pipe_ctx->stream_res.tg could be NULL, it is relying on the caller toensure the tg is not NULL.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve leaks in cow_file_rangeIn the buffered write path, the dirty page owns the qgroup reserve untilit creates an ordered_extent.Therefore, any errors that occur before the ordered_extent is createdmust free that reservation, or else the space is leaked. The fstestgeneric/475 exercises various IO error paths, and is able to triggererrors in cow_file_range where we fail to get to allocating the orderedextent. Note that because we *do* clear delalloc, we are likely toremove the inode from the delalloc list, so the inodes/pages to not haveinvalidate/launder called on them in the commit abort path.This results in failures at the unmount stage of the test that look like: BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leakedCases 2 and 3 in the out_reserve path both pertain to this type of leakand must free the reserved qgroup data. Because it is already an errorpath, I opted not to handle the possible errors inbtrfs_free_qgroup_data.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btnxpuart: Resolve TX timeout error in power save stress testThis fixes the tx timeout issue seen while running a stress test onbtnxpuart for couple of hours, such that the interval between two HCIcommands coincide with the power save timeout value of 2 seconds.Test procedure using bash script:hciconfig hci0 up//Enable Power Save featurehcitool -i hci0 cmd 3f 23 02 00 00while (true)do hciconfig hci0 leadv sleep 2 hciconfig hci0 noleadv sleep 2doneError log, after adding few more debug prints:Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00Bluetooth: hci0: Set UART break: on, status=0Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduledBluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00Can't set advertise mode on hci0: Connection timed out (110)Bluetooth: hci0: command 0x200a tx timeoutWhen the power save mechanism turns on UART break, and btnxpuart_tx_work()is scheduled simultaneously, psdata->ps_state is read as PS_STATE_AWAKE,which prevents the psdata->work from being scheduled, which is responsibleto turn OFF UART break.This issue is fixed by adding a ps_lock mutex around UART break on/off aswell as around ps_state read/write.btnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state isPS_STATE_SLEEP, it will first schedule psdata->work, and then it willreschedule itself once UART break has been turned off and ps_state isPS_STATE_AWAKE.Tested above script for 50,000 iterations and TX timeout error was notobserved anymore.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libxslt1 < 1.1.34-150400.3.13.1 (version in image is 1.1.34-150400.3.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: correct handling of extreme memory squeezeTesting with iperf3 using the "pasta" protocol splicer has revealeda problem in the way tcp handles window advertising in extreme memorysqueeze situations.Under memory pressure, a socket endpoint may temporarily advertisea zero-sized window, but this is not stored as part of the socket data.The reasoning behind this is that it is considered a temporary settingwhich shouldn't influence any further calculations.However, if we happen to stall at an unfortunate value of the currentwindow size, the algorithm selecting a new value will consistently failto advertise a non-zero window once we have freed up enough memory.This means that this side's notion of the current window size isdifferent from the one last advertised to the peer, causing the latterto not send any data to resolve the sitution.The problem occurs on the iperf3 server side, and the socket in questionis a completely regular socket with the default settings for thefedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.The following excerpt of a logging session, with own comments added,shows more in detail what is happening:// tcp_v4_rcv(->)// tcp_rcv_established(->)[5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====[5201<->39222]: tcp_data_queue(->)[5201<->39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0][5201<->39222]: tcp_data_queue(<-)[5201<->39222]: __tcp_transmit_skb(->) [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160][5201<->39222]: tcp_select_window(->)[5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0[5201<->39222]: tcp_select_window(<-)[5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160[5201<->39222]: [__tcp_transmit_skb(<-)[5201<->39222]: tcp_rcv_established(<-)[5201<->39222]: tcp_v4_rcv(<-)// Receive queue is at 85 buffers and we are out of memory.// We drop the incoming buffer, although it is in sequence, and decide// to send an advertisement with a window of zero.// We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means// we unconditionally shrink the window.[5201<->39222]: tcp_recvmsg_locked(->)[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160[5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368][5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0][5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160][5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes[5201<->39222]: tcp_recvmsg_locked(<-)// After each read, the algorithm for calculating the new receive// window in __tcp_cleanup_rbuf() finds it is too small to advertise// or to update tp->rcv_wnd.// Meanwhile, the peer thinks the window is zero, and will not send// any more data to trigger an update from the interrupt mode side.[5201<->39222]: tcp_recvmsg_locked(->)[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160[5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reset IRTE to host control if *new* route isn't postableRestore an IRTE back to host control (remapped or posted MSI mode) if the*new* GSI route prevents posting the IRQ directly to a vCPU, regardless ofthe GSI routing type. Updating the IRTE if and only if the new GSI is anMSI results in KVM leaving an IRTE posting to a vCPU.The dangling IRTE can result in interrupts being incorrectly delivered tothe guest, and in the worst case scenario can result in use-after-free,e.g. if the VM is torn down, but the underlying host IRQ isn't freed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix timeout on deleted connectionNOPIN response timer may expire on a deleted connection and crash withsuch logs:Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3dBUG: Kernel NULL pointer dereference on read at 0x00000000NIP strlcpy+0x8/0xb0LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410That is because nopin response timer may be re-started on nopin timerexpiration.Stop nopin timer before stopping the nopin response timer to be surethat no one of them will be re-started.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: ufs: Fix a hang in the error handlerufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latterfunction can only succeed if UFSHCD_EH_IN_PROGRESS is not set becauseresuming involves submitting a SCSI command and ufshcd_queuecommand()returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix thishang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() hasbeen called instead of before.Backtrace:__switch_to+0x174/0x338__schedule+0x600/0x9e4schedule+0x7c/0xe8schedule_timeout+0xa4/0x1c8io_schedule_timeout+0x48/0x70wait_for_common_io+0xa8/0x160 //waiting on START_STOPwait_for_completion_io_timeout+0x10/0x20blk_execute_rq+0xe4/0x1e4scsi_execute_cmd+0x108/0x244ufshcd_set_dev_pwr_mode+0xe8/0x250__ufshcd_wl_resume+0x94/0x354ufshcd_wl_runtime_resume+0x3c/0x174scsi_runtime_resume+0x64/0xa4rpm_resume+0x15c/0xa1c__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoingufshcd_err_handler+0x1a0/0xd08process_one_work+0x174/0x808worker_thread+0x15c/0x490kthread+0xf4/0x1ecret_from_fork+0x10/0x20[ bvanassche: rewrote patch description ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,raspberrypi_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearerThe reproduction steps:1. create a tun interface2. enable l2 bearer3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tuntipc: Started in network modetipc: Node identity 8af312d38a21, cluster identity 4711tipc: Enabled bearer , priority 1Oops: general protection faultKASAN: null-ptr-deref in rangeCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPTHardware name: QEMU Ubuntu 24.04 PCRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0the ub was in fact a struct dev.when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL orother media when other thread changes it.fix this by checking media_id.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Free invalid length skb in atmtcp_c_send().syzbot reported the splat below. [0]vcc_sendmsg() copies data passed from userspace to skb and passesit to vcc->dev->ops->send().atmtcp_c_send() accesses skb->data as struct atmtcp_hdr afterchecking if skb->len is 0, but it's not enough.Also, when skb->len == 0, skb and sk (vcc) were leaked becausedev_kfree_skb() is not called and sk_wmem_alloc adjustment is missingto revert atm_account_tx() in vcc_sendmsg(), which is expectedto be done in atm_pop_raw().Let's properly free skb with an invalid length in atmtcp_c_send().[0]:BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Revert atm_account_tx() if copy_from_iter_full() fails.In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc byatm_account_tx().It is expected to be reverted by atm_pop_raw() later called byvcc->dev->ops->send(vcc, skb).However, vcc_sendmsg() misses the same revert when copy_from_iter_full()fails, and then we will leak a socket.Let's factorise the revert part as atm_return_tx() and call it inthe failure path.Note that the corresponding sk_wmem_alloc operation can be found inalloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAXOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()when resizing hashtable because __GFP_NOWARN is unset.Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1[Why]If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updatedthen they can lead to a divide by zero in downstream callers likeCalculateVMAndRowBytes()[How]Initialize dummy value to a value to avoid divide by zero.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: add NULL check in automount_fullpathpage is checked for null in __build_path_from_dentry_optional_prefixwhen tcon->origin_fullpath is not set. However, the check is missing whenit is set.Add a check to prevent a potential NULL pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: prevent NULL deref in clip_push()Blamed commit missed that vcc_destroy_socket() callsclip_push() with a NULL skb.If clip_devs is NULL, clip_push() then crashes when readingskb->truesize.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()While testing null_blk with configfs, echo 0 > poll_queues will triggerfollowing panic:BUG: kernel NULL pointer dereference, address: 0000000000000010Oops: Oops: 0000 [#1] SMP NOPTICPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:__bitmap_or+0x48/0x70Call Trace: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned fromkcalloc(), and later ZERO_SIZE_PTR will be deferenced.Fix the problem by checking numgrps first in group_cpus_evenly(), andreturn NULL directly if numgrps is zero.[yukuai3@huawei.com: also fix the non-SMP version]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix NULL pointer in cache_set_flush()1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc().2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set().3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 }(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885).(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL.LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().As (1), in LINE#1885 callbch_cache_set_unregister()---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 }(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below:[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory[ 846.713242] bcache: register_bcache() error : failed to register device[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8[ 846.714790] PGD 0 P4D 0[ 846.715129] Oops: 0000 [#1] SMP PTI[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018[ 846.716451] Workqueue: events cache_set_flush [bcache][ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache][ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flushIn KVM guests with Hyper-V hypercalls enabled, the hypercallsHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EXallow a guest to request invalidation of portions of a virtual TLB.For this, the hypercall parameter includes a list of GVAs that are supposedto be invalidated.However, when non-canonical GVAs are passed, there is currently nofiltering in place and they are eventually passed to checked invocations ofINVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignoresnon-canonical addresses (effectively a no-op), Intel's INVVPID explicitlysignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]Hyper-V documents that invalid GVAs (those that are beyond a partition'sGVA space) are to be ignored. While not completely clear whether thisruling also applies to non-canonical GVAs, it is likely fine to make thatassumption, and manual testing on Azure confirms "real" Hyper-V interpretsthe specification in the same way.Skip non-canonical GVAs when processing the list of address to avoidtripping the INVVPID failure. Alternatively, KVM could filter out "bad"GVAs before inserting into the FIFO, but practically speaking the onlydownside of pushing validation to the final processing is that doing sois suboptimal for the guest, and no well-behaved guest will request TLBflushes for non-canonical addresses.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Fix in_atomic() handling in do_secure_storage_access()Kernel user spaces accesses to not exported pages in atomic contextincorrectly try to resolve the page fault.With debug options enabled call traces like this can be seen:BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39preempt_count: 1, expected: 0RCU nest depth: 0, expected: 0INFO: lockdep is turned off.Preemption disabled at:[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPTTainted: [W]=WARNHardware name: IBM 3931 A01 703 (LPAR)Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90INFO: lockdep is turned off.It is not allowed to take the mmap_lock while in atomic context. Thereforehandle such a secure storage access fault as if the accessed page is notmapped: the uaccess function will return -EFAULT, and the caller has todeal with this. Usually this means that the access is retried in processcontext, which allows to resolve the page fault (or in this case export thepage).
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add more checks for DSC / HUBP ONO guarantees[WHY]For non-zero DSC instances it's possible that the HUBP domain requiredto drive it for sequential ONO ASICs isn't met, potentially causingthe logic to the tile to enter an undefined state leading to a systemhang.[HOW]Add more checks to ensure that the HUBP domain matching the DSC instanceis appropriately powered.(cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check dce_hwseq before dereferencing it[WHAT]hws was checked for null earlier in dce110_blank_stream, indicating hwscan be null, and should be checked whenever it is used.(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: return 0 size for RSS key if not supportedReturning -EOPNOTSUPP from function returning u32 is leading tocast and invalid size value as a result.-EOPNOTSUPP as a size probably will lead to allocation fail.Command: ethtool -x eth0It is visible on all devices that don't have RSS caps set.[ 136.615917] Call Trace:[ 136.615921] [ 136.615927] ? __warn+0x89/0x130[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.615953] ? report_bug+0x164/0x190[ 136.615968] ? handle_bug+0x58/0x90[ 136.615979] ? exc_invalid_op+0x17/0x70[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.616028] __alloc_pages_noprof+0xe/0x20[ 136.616038] ___kmalloc_large_node+0x80/0x110[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0[ 136.616081] __kmalloc_noprof+0x32c/0x4c0[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170[ 136.616114] ethnl_default_doit+0x107/0x3d0[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160[ 136.616147] genl_rcv_msg+0x1b8/0x2c0[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10[ 136.616176] netlink_rcv_skb+0x58/0x110[ 136.616186] genl_rcv+0x28/0x40[ 136.616195] netlink_unicast+0x19b/0x290[ 136.616206] netlink_sendmsg+0x222/0x490[ 136.616215] __sys_sendto+0x1fd/0x210[ 136.616233] __x64_sys_sendto+0x24/0x30[ 136.616242] do_syscall_64+0x82/0x160[ 136.616252] ? __sys_recvmsg+0x83/0xe0[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210[ 136.616275] ? do_syscall_64+0x8e/0x160[ 136.616282] ? __count_memcg_events+0xa1/0x130[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30[ 136.616306] ? handle_mm_fault+0xae/0x2d0[ 136.616319] ? do_user_addr_fault+0x379/0x670[ 136.616328] ? clear_bhb_loop+0x45/0xa0[ 136.616340] ? clear_bhb_loop+0x45/0xa0[ 136.616349] ? clear_bhb_loop+0x45/0xa0[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 136.616369] RIP: 0033:0x7fd30ba7b047[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Release rproc->clean_table after rproc_attach() failsWhen rproc->state = RPROC_DETACHED is attached to remote processorthrough rproc_attach(), if rproc_handle_resources() returns failure,then the clean table should be released, otherwise the followingmemory leak will occur.unreferenced object 0xffff000086a99800 (size 1024):comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)hex dump (first 32 bytes):00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()When rproc->state = RPROC_DETACHED and rproc_attach() is usedto attach to the remote processor, if rproc_handle_resources()returns a failure, the resources allocated by imx_rproc_prepare()should be released, otherwise the following memory leak will occur.Since almost the same thing is done in imx_rproc_prepare() andrproc_resource_cleanup(), Function rproc_resource_cleanup() is ableto deal with empty lists so it is better to fix the "goto" statementsin rproc_attach(). replace the "unprepare_device" goto statement with"clean_up_resources" and get rid of the "unprepare_device" label.unreferenced object 0xffff0000861c5d00 (size 128):comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:raid10: cleanup memleak at raid10_make_requestIf raid10_read_request or raid10_write_request registers a newrequest and the REQ_NOWAIT flag is set, the code does notfree the malloc from the mempool.unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7eV4: changing backing tree to see if CKI tests will pass.The patch code has not changed between any versions.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: Fix stack memory use after return in raid1_reshapeIn the raid1_reshape function, newpool isallocated on the stack and assigned to conf->r1bio_pool.This results in conf->r1bio_pool.wait.head pointingto a stack address.Accessing this address later can lead to a kernel panic.Example access path:raid1_reshape(){ // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool;}raid1_read_request() or raid1_write_request(){ alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } }}mempool_free(){ if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); }}Fix:reinit conf->r1bio_pool.wait after assigning newpool.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix infinite recursive call of clip_push().syzbot reported the splat below. [0]This happens if we call ioctl(ATMARP_MKIP) more than once.During the first call, clip_mkip() sets clip_push() to vcc->push(),and the second call copies it to clip_vcc->old_push().Later, when the socket is close()d, vcc_destroy_socket() passesNULL skb to clip_push(), which calls clip_vcc->old_push(),triggering the infinite recursion.Let's prevent the second ioctl(ATMARP_MKIP) by checkingvcc->user_back, which is allocated by the first call as clip_vcc.Note also that we use lock_sock() to prevent racy calls.[0]:BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)Oops: stack guard page: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00RSP: 0018:ffffc9000d670000 EFLAGS: 00010246RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209eR10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7ff31c98e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226fR10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608cR13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix wraparounds of sk->sk_rmem_alloc.Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc);, which has the same problem fixed by commit 5a465a0da13e ("udp:Fix multiple wraparounds of sk->sk_rmem_alloc.").For example, if we set INT_MAX to SO_RCVBUFFORCE, the conditionis always false as the two operands are of int.Then, a single socket can eat as many skb as possible until OOMhappens, and we can see multiple wraparounds of sk->sk_rmem_alloc.Let's fix it by using atomic_add_return() and comparing the twovariables as unsigned int.Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 *After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion when building free space treeWhen building the free space tree with the block group tree featureenabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---This happens because we are processing an empty block group, which hasno extents allocated from it, there are no items for this block group,including the block group item since block group items are stored in adedicated tree when using the block group tree feature. It also meansthis is the block group with the highest start offset, so there are nohigher keys in the extent root, hence btrfs_search_slot_for_read()returns 1 (no higher key found).Fix this by asserting 'ret' is 0 only if the block group tree featureis not enabled, in which case we should find a block group item forthe block group since it's stored in the extent root and block groupitem keys are greater than extent item keys (the value forBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY andBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).In case 'ret' is 1, we just need to add a record to the free spacetree which spans the whole block group, and we can achieve this bymaking 'ret == 0' as the while loop's condition.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kasan: remove kasan_find_vm_area() to prevent possible deadlockfind_vm_area() couldn't be called in atomic_context. If find_vm_area() iscalled to reports vm area information, kasan can trigger deadlock like:CPU0 CPU1vmalloc(); alloc_vmap_area(); spin_lock(&vn->busy.lock) spin_lock_bh(&some_lock);
spin_lock(&some_lock); kasan_report(); print_report(); print_address_description(); kasan_find_vm_area(); find_vm_area(); spin_lock(&vn->busy.lock) // deadlock!To prevent possible deadlock while kasan reports, remove kasan_find_vm_area().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix oops due to non-existence of prealloc backlog structIf an AF_RXRPC service socket is opened and bound, but calls arepreallocated, then rxrpc_alloc_incoming_call() will oops because therxrpc_backlog struct doesn't get allocated until the first preallocation ismade.Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is nobacklog struct. This will cause the incoming call to be aborted.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: qcom: msm: mark certain pins as invalid for interruptsOn some platforms, the UFS-reset pin has no interrupt logic in TLMM butis nevertheless registered as a GPIO in the kernel. This enables theuser-space to trigger a BUG() in the pinctrl-msm driver by running, forexample: `gpiomon -c 0 113` on RB2.The exact culprit is requesting pins whose intr_detection_width settingis not 1 or 2 for interrupts. This hits a BUG() inmsm_gpio_irq_set_type(). Potentially crashing the kernel due to aninvalid request from user-space is not optimal, so let's go through thepins and mark those that would fail the check as invalid for the irq chipas we should not even register them as available irqs.This function can be extended if we determine that there are morecorner-cases like this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recv-recv race of completed callIf a call receives an event (such as incoming data), the call gets placedon the socket's queue and a thread in recvmsg can be awakened to go andprocess it. Once the thread has picked up the call off of the queue,further events will cause it to be requeued, and once the socket lock isdropped (recvmsg uses call->user_mutex to allow the socket to be used inparallel), a second thread can come in and its recvmsg can pop the call offthe socket queue again.In such a case, the first thread will be receiving stuff from the call andthe second thread will be blocked on call->user_mutex. The first threadcan, at this point, process both the event that it picked call for and theevent that the second thread picked the call for and may see the callterminate - in which case the call will be "released", decoupling the callfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the controlmessage).The first thread will return okay, but then the second thread will wake upholding the user_mutex and, if it sees that the call has been released bythe first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474!Fix this by just dequeuing the call and ignoring it if it is seen to bealready released. We can't tell userspace about it anyway as the user callID has become stale.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: add NULL check in eswitch lag checkThe function ice_lag_is_switchdev_running() is being called from outside ofthe LAG event handler code. This results in the lag->upper_netdev beingNULL sometimes. To avoid a NULL-pointer dereference, there needs to be acheck before it is dereferenced.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY modeWhen transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the codeassumed that the regulator should be disabled. However, if the regulatoris marked as always-on, regulator_is_enabled() continues to return true,leading to an incorrect attempt to disable a regulator which is notenabled.This can result in warnings such as:[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004_regulator_disable+0xe4/0x1a0[ 250.155652] unbalanced disables for VIN_SYS_5V0To fix this, we move the regulator control logic intotegra186_xusb_padctl_id_override() function since it's directly relatedto the ID override state. The regulator is now only disabled when the roletransitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_IDregister. This ensures that regulator enable/disable operations areproperly balanced and only occur when actually transitioning to/from hostmode.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: Don't register LEDs for genphyIf a PHY has no driver, the genphy driver is probed/removed directly inphy_attach/detach. If the PHY's ofnode has an "leds" subnode, then theLEDs will be (un)registered when probing/removing the genphy driver.This could occur if the leds are for a non-generic driver that isn'tloaded for whatever reason. Synchronously removing the PHY device inphy_detach leads to the following deadlock:rtnl_lock()ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock()There is a corresponding deadlock on the open/register side of things(and that one is reported by lockdep), but it requires a race while thisone is deterministic.Generic PHYs do not support LEDs anyway, so don't bother registeringthem.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP CamerasThe Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)report a HID sensor interface that is not actually implemented.Attempting to access this non-functional sensor via iio_info causessystem hangs as runtime PM tries to wake up an unresponsive sensor.Add these 2 devices to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init()devm_kasprintf() returns NULL on error. Currently, mt7925_thermal_init()does not check for this case, which results in a NULL pointerdereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: nvdec: Fix dma_alloc_coherent error checkCheck for NULL return value with dma_alloc_coherent, in line withRobin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (corsair-cpro) Validate the size of the received input bufferAdd buffer_recv_size to store the size of the received bytes.Validate buffer_recv_size in send_usb_cmd().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Delay put pmc->idev in mld_del_delrec()pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()does, the reference should be put after ip6_mc_clear_src() return.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Restrict conditions for adding duplicating netems to qdisc treenetem_enqueue's duplication prevention logic breaks when a netemresides in a qdisc tree with other netems - this can lead to asoft lockup and OOM loop in netem_dequeue, as seen in [1].Ensure that a duplicating netem cannot exist in a tree with othernetems.Previous approaches suggested in discussions in chronological order:1) Track duplication status or ttl in the sk_buff struct. Consideredtoo specific a use case to extend such a struct, though this wouldbe a resilient fix and address other previous and potential futureDOS bugs like the one described in loopy fun [2].2) Restrict netem_enqueue recursion depth like in act_mirred with aper cpu variable. However, netem_dequeue can call enqueue on itschild, and the depth restriction could be bypassed if the child is anetem.3) Use the same approach as in 2, but add metadata in netem_skb_cbto handle the netem_dequeue case and track a packet's involvementin duplication. This is an overly complex approach, and Jamalnotes that the skb cb can be overwritten to circumvent thissafeguard.4) Prevent the addition of a netem to a qdisc tree if its ancestralpath contains a netem. However, filters and actions can cause apacket to change paths when re-enqueued to the root from netemduplication, leading us to the current solution: prevent aduplicating netem from inhabiting the same tree as other netems.[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/[2] https://lwn.net/Articles/719297/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix crash when rebind ccp device for ccp.koWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebindingthe ccp device causes the following crash:$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 204.978026] #PF: supervisor write access in kernel mode[ 204.979126] #PF: error_code(0x0002) - not-present page[ 204.980226] PGD 0 P4D 0[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI...[ 204.997852] Call Trace:[ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0[ 205.001533] debugfs_create_dir+0x1f/0x170[ 205.002769] ? srso_return_thunk+0x5/0x5f[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp][ 205.005241] ccp5_init+0x8b2/0x960 [ccp][ 205.006469] ccp_dev_init+0xd4/0x150 [ccp][ 205.007709] sp_init+0x5f/0x80 [ccp][ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp][ 205.010165] ? srso_return_thunk+0x5/0x5f[ 205.011376] local_pci_probe+0x4f/0xb0[ 205.012584] pci_device_probe+0xdb/0x230[ 205.013810] really_probe+0xed/0x380[ 205.015024] __driver_probe_device+0x7e/0x160[ 205.016240] device_driver_attach+0x2f/0x60[ 205.017457] bind_store+0x7c/0xb0[ 205.018663] drv_attr_store+0x28/0x40[ 205.019868] sysfs_kf_write+0x5f/0x70[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0[ 205.022267] vfs_write+0x308/0x440[ 205.023453] ksys_write+0x6d/0xe0[ 205.024616] __x64_sys_write+0x1e/0x30[ 205.025778] x64_sys_call+0x16ba/0x2150[ 205.026942] do_syscall_64+0x56/0x1e0[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 205.029276] RIP: 0033:0x7fbc36f10104[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5This patch sets ccp_debugfs_dir to NULL after destroying it inccp5_debugfs_destroy, allowing the directory dentry to berecreated when rebinding the ccp device.Tested on AMD Ryzen 7 1700X.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: xilinx: vcu: unregister pll_post only if registered correctlyIf registration of pll_post is failed, it will be set to NULL or ERR,unregistering same will fail with following call trace:Unable to handle kernel NULL pointer dereference at virtual address 008pc : clk_hw_unregister+0xc/0x20lr : clk_hw_unregister_fixed_factor+0x18/0x30sp : ffff800011923850...Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible infinite loop in fib6_info_uses_dev()fib6_info_uses_dev() seems to rely on RCU without an explicitprotection.Like the prior fix in rt6_nlmsg_size(),we need to make sure fib6_del_route() or fib6_add_rt2node()have not removed the anchor from the list, or we risk an infinite loop.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Remove skb secpath if xfrm state is not foundHardware returns a unique identifier for a decrypted packet's xfrmstate, this state is looked up in an xarray. However, the state mighthave been freed by the time of this lookup.Currently, if the state is not found, only a counter is incremented.The secpath (sp) extension on the skb is not removed, resulting insp->len becoming 0.Subsequently, functions like __xfrm_policy_check() attempt to accessfields such as xfrm_input_state(skb)->xso.type (which dereferencessp->xvec[sp->len - 1]) without first validating sp->len. This leads toa crash when dereferencing an invalid state pointer.This patch prevents the crash by explicitly removing the secpathextension from the skb if the xfrm state is not found after hardwaredecryption. This ensures downstream functions do not operate on azero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-portEach window of a vop2 is usable by a specific set of video ports, so whilebinding the vop2, we look through the list of available windows trying tofind one designated as primary-plane and usable by that specific port.The code later wants to use drm_crtc_init_with_planes with that foundprimary plane, but nothing has checked so far if a primary plane wasactually found.For whatever reason, the rk3576 vp2 does not have a usable primary window(if vp0 is also in use) which brought the issue to light and ended in anull-pointer dereference further down.As we expect a primary-plane to exist for a video-port, add a check atthe end of the window-iteration and fail probing if none was found.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: clear initialized flag for deinit-ed srng listsIn a number of cases we see kernel panics on resume dueto ath11k kernel page fault, which happens under thefollowing circumstances:1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170Clear per-list ->initialized flag in ath11k_hal_srng_deinit().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iwlwifi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue since it mayreturn NULL pointer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type()In ath12k_dp_tx_get_encap_type(), the arvif parameter is only used toretrieve the ab pointer. In vdev delete sequence the arvif->ar couldbecome NULL and that would trigger kernel panic.Since the caller ath12k_dp_tx() already has a valid ab pointer, pass itdirectly to avoid panic and unnecessary dereferencing.PC points to "ath12k_dp_tx+0x228/0x988 [ath12k]"LR points to "ath12k_dp_tx+0xc8/0x988 [ath12k]".The Backtrace obtained is as follows:ath12k_dp_tx+0x228/0x988 [ath12k]ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k]ieee80211_process_measurement_req+0x320/0x348 [mac80211]ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211]ieee80211_tx_dequeue+0xb14/0x1518 [mac80211]ieee80211_tx_prepare_skb+0x224/0x254 [mac80211]ieee80211_xmit+0xec/0x100 [mac80211]__ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211]ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211]netdev_start_xmit+0x150/0x18cdev_hard_start_xmit+0x74/0xc0Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Check governor before using governor->nameCommit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name fromstruct devfreq") removes governor_name and uses governor->name to replaceit. But devfreq->governor may be NULL and directly usingdevfreq->governor->name may cause null pointer exception. Move the check ofgovernor to before using governor->name.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()The get_pd_power_uw() function can crash with a NULL pointer dereferencewhen em_cpu_get() returns NULL. This occurs when a CPU becomes impossibleduring runtime, causing get_cpu_device() to return NULL, which propagatesthrough em_cpu_get() and leads to a crash when em_span_cpus() dereferencesthe NULL pointer.Add a NULL check after em_cpu_get() and return 0 if unavailable,matching the existing fallback behavior in __dtpm_cpu_setup().[ rjw: Drop an excess empty code line ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()In the error paths after fb_info structure is successfully allocated,the memory allocated in fb_deferred_io_init() for info->pagerefs is notfreed. Fix that by adding the cleanup function on the error path.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: make rdev_addable usable for rcu modeOur testcase trigger panic:BUG: kernel NULL pointer dereference, address: 00000000000000e0...Oops: Oops: 0000 [#1] SMP NOPTICPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94PREEMPT(none)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Workqueue: md_misc md_start_syncRIP: 0010:rdev_addable+0x4d/0xf0...Call Trace: md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 Modules linked in: raid10CR2: 00000000000000e0---[ end trace 0000000000000000 ]---RIP: 0010:rdev_addable+0x4d/0xf0md_spares_need_change in md_start_sync will call rdev_addable whichprotected by rcu_read_lock/rcu_read_unlock. This rcu context will helpprotect rdev won't be released, but rdev->mddev will be set to NULLbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this byusing READ_ONCE and check does rdev->mddev still alive.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: drop UFO packets in udp_rcv_segment()When sending a packet with virtio_net_hdr to tun device, if the gso_typein virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdrsize, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set optionUDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcvhook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will tryto pull udphdr, but the skb size has been segmented to gso size, whichleads to this crash.Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")introduces segmentation in UDP receive path only for GRO, which was neverintended to be used for UFO, so drop UFO packets in udp_rcv_segment().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Clean up allocated IRQs on unplugWhen the root of a nested PCIe bridge configuration is unplugged, thepnv_php driver leaked the allocated IRQ resources for the child bridges'hotplug event notifications, resulting in a panic.Fix this by walking all child buses and deallocating all its IRQ resourcesbefore calling pci_hp_remove_devices().Also modify the lifetime of the workqueue at struct pnv_php_slot::wq sothat it is only destroyed in pnv_php_free_slot(), instead ofpnv_php_disable_irq(). This is required since pnv_php_disable_irq() willnow be called by workers triggered by hot unplug interrupts, so theworkqueue needs to stay allocated.The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec[bhelgaas: tidy comments]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-dereffb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannotallocate a struct fb_modelist. If that happens, the modelist stays empty butthe driver continues to register. Add a check for its return value to preventpoteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev:Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var").
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cpcap-charger: Fix null check for power_supply_get_by_nameIn the cpcap_usb_detect() function, the power_supply_get_by_name()function may return `NULL` instead of an error pointer.To prevent potential null pointer dereferences, Added a null check.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: davinci: Add NULL check in davinci_lpsc_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,davinci_lpsc_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue and ensuringno resources are left allocated.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Disable migration in nf_hook_run_bpf().syzbot reported that the netfilter bpf prog can be called withoutmigration disabled in xmit path.Then the assertion in __bpf_prog_run() fails, triggering the splatbelow. [0]Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().[0]:BUG: assuming non migratable context at ./include/linux/filter.h:703in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe7d365d407Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ffRSP:
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()Callers of wdev_chandef() must hold the wiphy mutex.But the worker cfg80211_propagate_cac_done_wk() never takes the lock.Which triggers the warning below with the mesh_peer_connected_dfstest from hostapd and not (yet) released mac80211 code changes:WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165Modules linked in:CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cfWorkqueue: cfg80211 cfg80211_propagate_cac_done_wkStack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64irq event stamp: 614611hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xafhardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xafsoftirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Check device memory pointer before usageAdd a NULL check before accessing device memory to prevent a crash ifdev->dm allocation in mlx5_init_once() fails.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()Preserve the error code if iwl_setup_deferred_work() fails. The currentcode returns ERR_PTR(0) (which is NULL) on this path. I believe themissing error code potentially leads to a use after free involvingdebugfs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:[ceph] parse_longname(): strrchr() expects NUL-terminated string... and parse_longname() is not guaranteed that. That's the reasonwhy it uses kmemdup_nul() to build the argument for kstrtou64();the problem is, kstrtou64() is not the only thing that need it.Just get a NUL-terminated copy of the entire thing and be donewith that...
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_modeAndrei Lalaev reported a NULL pointer deref when a CAN device isrestarted from Bus Off and the driver does not implement the structcan_priv::do_set_mode callback.There are 2 code path that call struct can_priv::do_set_mode:- directly by a manual restart from the user space, via can_changelink()- delayed automatic restart after bus off (deactivated by default)To prevent the NULL pointer deference, refuse a manual restart orconfigure the automatic restart delay in can_changelink() and reportthe error via extack to user space.As an additional safety measure let can_restart() return an error ifcan_priv::do_set_mode is not set instead of dereferencing itunchecked.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix NULL dereference on unbind due to stale coupling dataFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs canlead to NULL pointer dereference when regulators are accessed post-unbind.This can happen during runtime PM or other regulator operations that relyon coupling metadata.For example, on ridesx4, unbinding the 'reg-dummy' platform device triggersa panic in regulator_lock_recursive() due to stale coupling state.Ensure n_coupled is set to 0 to prevent access to invalid pointers.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to changeto different stacks along with the Shadow Call Stack if it is enabled.Those two stack changes cannot be done atomically and both functionscan be interrupted by SErrors or Debug Exceptions which, though unlikely,is very much broken : if interrupted, we can end up with mismatched stacksand Shadow Call Stack leading to clobbered stacks.In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,but x18 stills points to the old task's SCS. When the interrupt handlertries to save the task's SCS pointer, it will save the old taskSCS pointer (x18) into the new task struct (pointed to by SP_EL0),clobbering it.In `call_on_irq_stack()`, it can happen when switching from the task stackto the IRQ stack and when switching back. In both cases, we can beinterrupted when the SCS pointer points to the IRQ SCS, but SP points tothe task stack. The nested interrupt handler pushes its return addresseson the IRQ SCS. It then detects that SP points to the task stack,calls `call_on_irq_stack()` and clobbers the task SCS pointer withthe IRQ SCS pointer, which it will also use !This leads to tasks returning to addresses on the wrong SCS,or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACKor FPAC if enabled.This is possible on a default config, but unlikely.However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked andinstead the GIC is responsible for filtering what interrupts the CPUshould receive based on priority.Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPUeven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*frequently depending on the system configuration and workload, leadingto unpredictable kernel panics.Completely mask DAIF in `cpu_switch_to()` and restore it when returning.Do the same in `call_on_irq_stack()`, but restore and mask aroundthe branch.Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistencyof behaviour between all configurations.Introduce and use an assembly macro for saving and masking DAIF,as the existing one saves but only masks IF.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: qup: jump out of the loop in case of timeoutOriginal logic only sets the return value but doesn't jump out of theloop if the bus is kept active by a client. This is not expected. Amalicious or buggy i2c client can hang the kernel in this case andshould be avoided. This is observed during a long time test with aPCA953x GPIO extender.Fix it by changing the logic to not only sets the return value, but alsojumps out of the loop and return to the caller with -ETIMEDOUT.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Fix OOB read due to missing payload bound checkCurrently, The event_seq_changed() handler processes a variable numberof properties sent by the firmware. The number of properties is indicatedby the firmware and used to iterate over the payload. However, thepayload size is not being validated against the actual message length.This can lead to out-of-bounds memory access if the firmware provides aproperty count that exceeds the data available in the payload. Such acondition can result in kernel crashes or potential information leaks ifmemory beyond the buffer is accessed.Fix this by properly validating the remaining size of the payload beforeeach property access and updating bounds accordingly as properties areparsed.This ensures that property parsing is safely bounded within the receivedmessage buffer and protects against malformed or malicious firmwarebehavior.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()The buffer length check before calling uvc_parse_format() only ensuredthat the buffer has at least 3 bytes (buflen > 2), buf the functionaccesses buffer[3], requiring at least 4 bytes.This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.Fix it by checking that the buffer has at least 4 bytes inuvc_parse_format().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Memory hot remove unmaps and tears down various kernel page table regionsas required. The ptdump code can race with concurrent modifications ofthe kernel page tables. When leaf entries are modified concurrently, thedump code may log stale or inconsistent information for a VA range, butthis is otherwise not harmful.But when intermediate levels of kernel page table are freed, the dump codewill continue to use memory that has been freed and potentiallyreallocated for another purpose. In such cases, the ptdump code maydereference bogus addresses, leading to a number of potential problems.To avoid the above mentioned race condition, platforms such as arm64,riscv and s390 take memory hotplug lock, while dumping kernel page tablevia the sysfs interface /sys/kernel/debug/kernel_page_tables.Similar race condition exists while checking for pages that might havebeen marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pageswhich in turn calls ptdump_check_wx(). Instead of solving this racecondition again, let's just move the memory hotplug lock inside genericptdump_check_wx() which will benefit both the scenarios.Drop get_online_mems() and put_online_mems() combination from all existingplatform ptdump code paths.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix panic during namespace deletion with VFThe existing code move the VF NIC to new namespace when NETDEV_REGISTER isreceived on netvsc NIC. During deletion of the namespace,default_device_exit_batch() >> default_device_exit_net() is called. Whennetvsc NIC is moved back and registered to the default namespace, itautomatically brings VF NIC back to the default namespace. This will causethe default_device_exit_net() >> for_each_netdev_safe loop unable to detectthe list end, and hit NULL ptr:[ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0[ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010[ 231.450246] #PF: supervisor read access in kernel mode[ 231.450579] #PF: error_code(0x0000) - not-present page[ 231.450916] PGD 17b8a8067 P4D 0[ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI[ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY[ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 231.452692] Workqueue: netns cleanup_net[ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0[ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00[ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246[ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb[ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564[ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000[ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340[ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340[ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000[ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0[ 231.458434] Call Trace:[ 231.458600] [ 231.458777] ops_undo_list+0x100/0x220[ 231.459015] cleanup_net+0x1b8/0x300[ 231.459285] process_one_work+0x184/0x340To fix it, move the ns change to a workqueue, and take rtnl_lock to avoidchanging the netdev list when default_device_exit_net() is using it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: use old 'nbands' while purging unused classesShuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify()after recent changes from Lion [2]. The problem is: in ets_qdisc_change()we purge unused DWRR queues; the value of 'q->nbands' is the new one, andthe cleanup should be done with the old one. The problem is here since myfirst attempts to fix ets_qdisc_change(), but it surfaced again after therecent qdisc len accounting fixes. Fix it purging idle DWRR queues beforeassigning a new value of 'q->nbands', so that all purge operations find aconsistent configuration: - old 'q->nbands' because it's needed by ets_class_find() - old 'q->nstrict' because it's needed by ets_class_is_strict() BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab RSP: 0018:ffffba186009f400 EFLAGS: 00010202 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000 FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ets_class_qlen_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_qdisc.constprop.0+0x216/0x7f0 tc_modify_qdisc+0x7c/0x120 rtnetlink_rcv_msg+0x145/0x3f0 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x245/0x390 netlink_sendmsg+0x21b/0x470 ____sys_sendmsg+0x39d/0x3d0 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x7d/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f2155114084 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix race between polling and detachingsyzbot reports a use-after-free in comedi in the below link, which isdue to comedi gladly removing the allocated async area even though pollrequests are still active on the wait_queue_head inside of it. This cancause a use-after-free when the poll entries are later triggered orremoved, as the memory for the wait_queue_head has been freed. We needto check there are no tasks queued on any of the subdevices' wait queuesbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`ioctl.Tasks will read-lock `dev->attach_lock` before adding themselves to thesubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctlhandler by write-locking `dev->attach_lock` before checking that all ofthe subdevices are safe to be deleted. This includes testing for anysleepers on the subdevices' wait queues. It remains locked until thedevice has been detached. This requires the `comedi_device_detach()`function to be refactored slightly, moving the bulk of it into newfunction `comedi_device_detach_locked()`.Note that the refactor of `comedi_device_detach()` results in`comedi_device_cancel_all()` now being called while `dev->attach_lock`is write-locked, which wasn't the case previously, but that does notmatter.Thanks to Jens Axboe for diagnosing the problem and co-developing thispatch.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix uninited ptr deref in block/scsi layoutThe error occurs on the third attempt to encode extents. When functionext_tree_prepare_commit() reallocates a larger buffer to retry encodingextents, the "layoutupdate_pages" page array is initialized only after theretry loop. But ext_tree_free_commitdata() is called on every iterationand tries to put pages in the array, thus dereferencing uninitializedpointers.An additional problem is that there is no limit on the maximum possiblebuffer_size. When there are too many extents, the client may create alayoutcommit that is larger than the maximum possible RPC size acceptedby the server.During testing, we observed two typical scenarios. First, one memory pagefor extents is enough when we work with small files, append data to theend of the file, or preallocate extents before writing. But when we filla new large file without preallocating, the number of extents can be huge,and counting the number of written extents in ext_tree_encode_commit()does not help much. Since this number increases even more betweenunlocking and locking of ext_tree, the reallocated buffer may not belarge enough again and again.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serparIn w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We addcheck on msg[0].len to prevent crash.Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null andmsg[0].len is zero, former checks on msg[0].buf would be passed. If accessingmsg[0].buf[2] without sanity check, null pointer deref would happen. We addcheck on msg[0].len to prevent crash. Similar issue occurs when accessmsg[1].buf[0] and msg[1].buf[1].Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix null pointer accessWriting a string without delimiters (' ', '\n', '\0') to the undergpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profilewill result in a null pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()When the volume header contains erroneous values that do not reflectthe actual state of the filesystem, hfsplus_fill_super() assumes thatthe attributes file is not yet created, which later results in hittingBUG_ON() when hfsplus_create_attributes_file() is called. Replace thisBUG_ON() with -EIO error with a message to suggest running fsck tool.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix slab-out-of-bounds in hfs_bnode_read()This patch introduces is_bnode_offset_valid() method that checksthe requested offset value. Also, it introducescheck_and_correct_requested_length() method that checks andcorrect the requested length (if it is necessary). These methodsare used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(),hfs_bnode_copy(), and hfs_bnode_move() with the goal to preventthe access out of allocated memory and triggering the crash.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix refcount leak on table dumpThere is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...While its very unlikely, its possible that ct == last.If this happens, then the refcount of ct was already incremented.This 2nd increment is never undone.This prevents the conntrack object from being released, which in turnkeeps prevents cnet->count from dropping back to 0.This will then block the netns dismantle (or conntrack rmmod) asnf_conntrack_cleanup_net_list() will wait forever.This can be reproduced by running conntrack_resize.sh selftest in a loop.It takes ~20 minutes for me on a preemptible kernel on average beforeI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);But this reference counting isn't needed in the first place.We can just store a cookie value instead.A followup patch will do the same for ctnetlink_exp_dump_table,it looks to me as if this has the same problem and likectnetlink_dump_table, we only need a 'skip hint', not the actualobject so we can apply the same cookie strategy there as well.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:habanalabs: fix UAF in export_dmabuf()As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().habanalabs export_dmabuf() calls it and then proceeds to access theobjects destroyed on close. In particular, it grabs an extra reference toanother struct file that will be dropped as part of ->release() for ours;that "will be" is actually "might have already been".Fix that by reserving descriptor before anything else and do fd_install()only when everything had been set up. As a side benefit, we no longerhave the failure exit with file already created, but reference tounderlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet;unlike dma_buf_fd(), fd_install() can't fail.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()Lei Lu recently reported that nfsd4_setclientid_confirm() did not checkthe return value from get_client_locked(). a SETCLIENTID_CONFIRM couldrace with a confirmed client expiring and fail to get a reference. Thatcould later lead to a UAF.Fix this by getting a reference early in the case where there is anextant confirmed client. If that fails then treat it as if there were noconfirmed client found at all.In the case where the unconfirmed client is expiring, just fail andreturn the result from get_client_locked().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix_devices: add phy_mask for ax88772 mdio busWithout setting phy_mask for ax88772 mdio bus, current driver may createat most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phydevice will bind to net phy driver. This is creating issue during systemsuspend/resume since phy_polling_mode() in phy_state_machine() willdirectly deference member of phydev->drv for non-main phy devices. ThenNULL pointer dereference issue will occur. Due to only external phy orinternal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoudthe issue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: avoid infinite retry looping in netlink_unicast()netlink_attachskb() checks for the socket's read memory allocationconstraints. Firstly, it has: rmem < READ_ONCE(sk->sk_rcvbuf)to check if the just increased rmem value fits into the socket's receivebuffer. If not, it proceeds and tries to wait for the memory under: rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)The checks don't cover the case when skb->truesize + sk->sk_rmem_alloc isequal to sk->sk_rcvbuf. Thus the function neither successfully acceptsthese conditions, nor manages to reschedule the task - and is called inretry loop for indefinite time which is caught as: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: dump_stack lib/dump_stack.c:120 nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105 nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62 rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335 rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590 update_process_times kernel/time/timer.c:1953 tick_sched_handle kernel/time/tick-sched.c:227 tick_sched_timer kernel/time/tick-sched.c:1399 __hrtimer_run_queues kernel/time/hrtimer.c:1652 hrtimer_interrupt kernel/time/hrtimer.c:1717 __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113 asm_call_irq_on_stack arch/x86/entry/entry_64.S:808 netlink_attachskb net/netlink/af_netlink.c:1234 netlink_unicast net/netlink/af_netlink.c:1349 kauditd_send_queue kernel/audit.c:776 kauditd_thread kernel/audit.c:897 kthread kernel/kthread.c:328 ret_from_fork arch/x86/entry/entry_64.S:304Restore the original behavior of the check which commit in Fixesaccidentally missed when restructuring the code.Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 power domain descriptors, tooUAC3 power domain descriptors need to be verified with its variablebLength for avoiding the unexpected OOB accesses by maliciousfirmware, too.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: commit partial buffers on retryRing provided buffers are potentially only valid within the singleexecution context in which they were acquired. io_uring deals with thisand invalidates them on retry. But on the networking side, ifMSG_WAITALL is set, or if the socket is of the streaming type and toolittle was processed, then it will hang on to the buffer rather thanrecycle or commit it. This is problematic for two reasons:1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.Fix this by disallowing partial retries from pinning a provided bufferacross multiple executions, if ring provided buffers are used.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix UAF on smcsk after smc_listen_out()BPF CI testing report a UAF issue: [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590The direct cause of this issue is that after smc_listen_out_connected(),newclcsock->sk may be NULL since it will releases the smcsk. Therefore,if the application closes the socket immediately after accept,newclcsock->sk can be NULL. A possible execution order could be asfollows:smc_listen_work | userspace-----------------------------------------------------------------lock_sock(sk) |smc_listen_out_connected() || \- smc_listen_out || | \- release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | \- socket->sk = NULL;/* newclcsock->sk is NULL now */SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))Since smc_listen_out_connected() will not fail, simply swapping the orderof the code can easily fix this issue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: prevent ethtool ops after shutdownA crash can occur if an ethtool operation is invokedafter shutdown() is called.shutdown() is invoked during system shutdown to stop DMA operationswithout performing expensive deallocations. It is discouraged tounregister the netdev in this path, so the device may still be visibleto userspace and kernel helpers.In gve, shutdown() tears down most internal data structures. If anethtool operation is dispatched after shutdown(), it will dereferencefreed or NULL pointers, leading to a kernel panic. While gracefulshutdown normally quiesces userspace before invoking the rebootsyscall, forced shutdowns (as observed on GCP VMs) can still triggerthis path.Fix by calling netif_device_detach() in shutdown().This marks the device as detached so the ethtool ioctl handlerwill skip dispatching operations to the driver.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix_devices: Fix PHY address mask in MDIO bus initializationSyzbot reported shift-out-of-bounds exception on MDIO bus initialization.The PHY address should be masked to 5 bits (0-31). Without thismask, invalid PHY addresses could be used, potentially causing issueswith MDIO bus operations.Fix this by masking the PHY address with 0x1f (31 decimal) to ensureit stays within the valid range.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix race conditions in ppp_fill_forward_pathppp_fill_forward_path() has two race conditions:1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic.2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.Fix these by using a lockless RCU approach:- Use list_first_or_null_rcu() to safely test and access the first list entry.- Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal.- Check for a NULL pch->chan before dereferencing it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()The function mod_hdcp_hdcp1_create_session() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference.Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.This is similar to the commit c3e9826a2202("drm/amd/display: Add null pointer check for get_first_active_display()").(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix backlog accounting in qdisc_dequeue_internalThis issue applies for the following qdiscs: hhf, fq, fq_codel, andfq_pie, and occurs in their change handlers when adjusting to the newlimit. The problem is the following in the values passed to thesubsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).To fix this issue, the codepath for all clients of qdisc_dequeue_internalhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.qdisc_dequeue_internal handles the backlog adjustments for all cases thatdo not directly use the dequeue handler.The old fq_codel_change limit adjustment loop accumulated the arguments tothe subsequent qdisc_tree_reduce_backlog call through the cstats field.However, this is confusing and error prone as fq_codel_dequeue could alsopotentially mutate this field (which qdisc_dequeue_internal calls in thenon gso_skb case), so we have unified the code here with other qdiscs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULLIf metric table address is not allocated, accessing metrics_bin willresult in a NULL pointer dereference, so add a check.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().When the nvif_vmm_type is invalid, we will return error directlywithout freeing the args in nvif_vmm_ctor(), which leading a memoryleak. Fix it by setting the ret -EINVAL and goto done.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helperSince 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")resctrl_cpu_detect() has been moved from common CPU initialization code tothe vendor-specific BSP init helper, while Hygon didn't put that call in theircode.This triggers a division by zero fault during early booting stage on ourmachines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() triesto calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernelbuffer is allocated to hold `insn->n` samples (each of which is an`unsigned int`). For some instruction types, `insn->n` samples arecopied back to user-space, unless an error code is being returned. Theproblem is that not all the instruction handlers that need to returndata to userspace fill in the whole `insn->n` samples, so that there isan information leak. There is a similar syzbot report for`do_insnlist_ioctl()`, although it does not have a reproducer for it atthe time of writing.One culprit is `insn_rw_emulate_bits()` which is used as the handler for`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not havea specific handler for that instruction, but do have an `INSN_BITS`handler. For `INSN_READ` it only fills in at most 1 sample, so if`insn->n` is greater than 1, the remaining `insn->n - 1` samples copiedto userspace will be uninitialized kernel data.Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. Itnever returns an error, even if it fails to fill the buffer.Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making surethat uninitialized parts of the allocated buffer are zeroed beforehandling each instruction.Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fixreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is notalways necessary to clear the whole buffer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl726: Prevent invalid irq numberThe reproducer passed in an irq number(0x80008000) that was too large,which triggered the oob.Added an interrupt number check to prevent users from passing in an irqnumber that was too large.If `it->options[1]` is 31, then `1 << it->options[1]` is still invalidbecause it shifts a 1-bit into the sign bit (which is UB in C).Possible solutions include reducing the upper bound on the`it->options[1]` value to 30 or lower, or using `1U << it->options[1]`.The old code would just not attempt to request the IRQ if the`options[1]` value were invalid. And it would still configure thedevice without interrupts even if the call to `request_irq` returned anerror. So it would be better to combine this test with the test below.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Make insn_rw_emulate_bits() do insn->n samplesThe `insn_rw_emulate_bits()` function is used as a default handler for`INSN_READ` instructions for subdevices that have a handler for`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a defaulthandler for `INSN_WRITE` instructions for subdevices that have a handlerfor `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the`INSN_READ` or `INSN_WRITE` instruction handling with a constructed`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`instructions are supposed to be able read or write multiple samples,indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currentlyonly handles a single sample. For `INSN_READ`, the comedi core willcopy `insn->n` samples back to user-space. (That triggered KASANkernel-infoleak errors when `insn->n` was greater than 1, but that isbeing fixed more generally elsewhere in the comedi core.)Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or returnan error, to conform to the general expectation for `INSN_READ` and`INSN_WRITE` handlers.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid a NULL pointer dereference[WHY]Although unlikely drm_atomic_get_new_connector_state() ordrm_atomic_get_old_connector_state() can return NULL.[HOW]Check returns before dereference.(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix SCCB present checkTracing code called by the SCLP interrupt handler contains early exitsif the SCCB address associated with an interrupt is NULL. This check isperformed after physical to virtual address translation.If the kernel identity mapping does not start at address zero, theresulting virtual address is never zero, so that the NULL checks won'twork. Subsequently this may result in incorrect accesses to the firstpage of the identity mapping.Fix this by introducing a function that handles the NULL case beforeaddress translation.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a race when updating an existing writeAfter nfs_lock_and_join_requests() tests for whether the request isstill attached to the mapping, nothing prevents a call tonfs_inode_remove_request() from succeeding until we actually lock thepage group.The reason is that whoever called nfs_inode_remove_request() doesn'tnecessarily have a lock on the page group head.So in order to avoid races, let's take the page group lock earlier innfs_lock_and_join_requests(), and hold it across the removal of therequest in nfs_inode_remove_request().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: pfr_update: Fix the driver update version checkThe security-version-number check should be used ratherthan the runtime version check for driver updates.Otherwise, the firmware update would fail when the update binary hada lower runtime version number than the current one.[ rjw: Changelog edits ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net, hsr: reject HSR frame if skb can't hold tagReceiving HSR frame with insufficient space to hold HSR tag in the skbcan result in a crash (kernel BUG):[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1[ 45.392559] ------------[ cut here ]------------[ 45.392912] kernel BUG at net/core/skbuff.c:211![ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)[ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0[ 45.402911] Call Trace:[ 45.403105] [ 45.404470] skb_push+0xcd/0xf0[ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0[ 45.406513] br_forward_finish+0x128/0x260[ 45.408483] __br_forward+0x42d/0x590[ 45.409464] maybe_deliver+0x2eb/0x420[ 45.409763] br_flood+0x174/0x4a0[ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0[ 45.411618] br_handle_frame+0xac3/0x1230[ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0[ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0[ 45.424478] __netif_receive_skb+0x22/0x170[ 45.424806] process_backlog+0x242/0x6d0[ 45.425116] __napi_poll+0xbb/0x630[ 45.425394] net_rx_action+0x4d1/0xcc0[ 45.427613] handle_softirqs+0x1a4/0x580[ 45.427926] do_softirq+0x74/0x90[ 45.428196] This issue was found by syzkaller.The panic happens in br_dev_queue_push_xmit() once it receives acorrupted skb with ETH header already pushed in linear data. When itattempts the skb_push() call, there's not enough headroom andskb_push() panics.The corrupted skb is put on the queue by HSR layer, which makes asequence of unintended transformations when it receives a specificcorrupted HSR frame (with incomplete TAG).Fix it by dropping and consuming frames that are not long enough tocontain both ethernet and hsr headers.Alternative fix would be to check for enough headroom before skb_push()in br_dev_queue_push_xmit().In the reproducer, this is injected via AF_PACKET, but I don't easilysee why it couldn't be sent over the wire from adjacent network.Further Details:In the reproducer, the following network interface chain is set up: ────────────────┐ ────────────────┐| veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ ────────────────┘ ────────────────┘ | | ──────┐ ├─┤ hsr0 ├───┐ | ──────┘ | ────────────────┐ ────────────────┐ | | ────────┐| veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ ┤ | ────────────────┘ ────────────────┘ ┼ bridge | || | | ────────┘ | ───────┐ | | ... ├──────┘ ───────┘To trigger the events leading up to crash, reproducer sends a corruptedHSR fr---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix a Null pointer dereference vulnerability[Why]A null pointer dereference vulnerability exists in the AMD display driver's(DC module) cleanup function dc_destruct().When display control context (dc->ctx) construction fails(due to memory allocation failure), this pointer remains NULL.During subsequent error handling when dc_destruct() is called,there's no NULL check before dereferencing the perf_trace member(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.[How]Check if dc->ctx is non-NULL before dereferencing.(Updated commit text and removed unnecessary error message)(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: protect against spurious interrupts during probeMake sure the interrupt handler is initialized before the interrupt isregistered.If the IRQ is registered before hfi_create(), it's possible that aninterrupt fires before the handler setup is complete, leading to a NULLdereference.This error condition has been observed during system boot on Rb3Gen2.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Add a check for packet size after reading from shared memoryAdd a check to ensure that the packet size does not exceed the number ofavailable words after reading the packet header from shared memory. Thisensures that the size provided by the firmware is safe to process andprevent potential out-of-bounds memory access.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()In the interrupt handler rain_interrupt(), the buffer full check onrain->buf_len is performed before acquiring rain->buf_lock. Thiscreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, asrain->buf_len is concurrently accessed and modified in the workhandler rain_irq_work_handler() under the same lock.Multiple interrupt invocations can race, with each reading buf_lenbefore it becomes full and then proceeding. This can lead to bothinterrupts attempting to write to the buffer, incrementing buf_lenbeyond its capacity (DATA_SIZE) and causing a buffer overflow.Fix this bug by moving the spin_lock() to before the buffer fullcheck. This ensures that the check and the subsequent buffer modificationare performed atomically, preventing the race condition. An correspondingspin_unlock() is added to the overflow path to correctly release thelock.This possible bug was found by an experimental static analysis tooldeveloped by our team.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Lock resolution while streamingWhen an program is streaming (ffplay) and another program (qv4l2)changes the TV standard from NTSC to PAL, the kernel crashes due to tryingto copy to unmapped memory.Changing from NTSC to PAL increases the resolution in the usbtv struct,but the video plane buffer isn't adjusted, so it overflows.[hverkuil: call vb2_is_busy instead of vb2_is_streaming]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Validate length in packet header before skb_put()When receiving a vsock packet in the guest, only the virtqueue buffersize is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,virtio_vsock_skb_rx_put() uses the length from the packet header as thelength argument to skb_put(), potentially resulting in SKB overflow ifthe host has gone wonky.Validate the length as advertised by the packet header before callingvirtio_vsock_skb_rx_put().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: bno055: fix OOB access of hw_xlate arrayFix a potential out-of-bounds array access of the hw_xlate array inbno055.c.In bno055_get_regmask(), hw_xlate was iterated over the length of thevals array instead of the length of the hw_xlate array. In the case ofbno055_gyr_scale, the vals array is larger than the hw_xlate array,so this could result in an out-of-bounds access. In practice, thisshouldn't happen though because a match should always be found whichbreaks out of the for loop before it iterates beyond the end of thehw_xlate array.By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can besure we are iterating over the correct length.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - flush misc workqueue during device shutdownRepeated loading and unloading of a device specific QAT driver, forexample qat_4xxx, in a tight loop can lead to a crash due to ause-after-free scenario. This occurs when a power management (PM)interrupt triggers just before the device-specific driver (e.g.,qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remainsloaded.Since the driver uses a shared workqueue (`qat_misc_wq`) across alldevices and owned by intel_qat.ko, a deferred routine from thedevice-specific driver may still be pending in the queue. If thisroutine executes after the driver is unloaded, it can dereference freedmemory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50To prevent this, flush the misc workqueue during device shutdown toensure that all pending work items are completed before the driver isunloaded.Note: This approach may slightly increase shutdown latency if theworkqueue contains jobs from other devices, but it ensures correctnessand stability.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: fix panic due to PSLVERRWhen the PSLVERR_RESP_EN parameter is set to 1, the device generatesan error response if an attempt is made to read an empty RBR (ReceiveBuffer Register) while the FIFO is enabled.In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokesdw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latterfunction enables the FIFO via serial_out(p, UART_FCR, p->fcr).Execution proceeds to the serial_port_in(port, UART_RX).This satisfies the PSLVERR trigger condition.When another CPU (e.g., using printk()) is accessing the UART (UARTis busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enterdw8250_force_idle().Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lockto fix this issue.Panic backtrace:[ 0.442336] Oops - unknown exception [#1][ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e...[ 0.442416] console_on_rootfs+0x26/0x70
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ism: fix concurrency management in ism_cmd()The s390x ISM device data sheet clearly states that only onerequest-response sequence is allowable per ISM function at any point intime. Unfortunately as of today the s390/ism driver in Linux does nothonor that requirement. This patch aims to rectify that.This problem was discovered based on Aliaksei's bug report which statesthat for certain workloads the ISM functions end up entering error state(with PEC 2 as seen from the logs) after a while and as a consequenceconnections handled by the respective function break, and for futureconnection requests the ISM device is not considered -- given it is in adysfunctional state. During further debugging PEC 3A was observed aswell.A kernel message like[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61ais a reliable indicator of the stated function entering error statewith PEC 2. Let me also point out that a kernel message like[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recoveryis a reliable indicator that the ISM function won't be auto-recoveredbecause the ISM driver currently lacks support for it.On a technical level, without this synchronization, commands (inputs tothe FW) may be partially or fully overwritten (corrupted) by another CPUtrying to issue commands on the same function. There is hard evidence thatthis can lead to DMB token values being used as DMB IOVAs, leading toPEC 2 PCI events indicating invalid DMA. But this is only one of thefailure modes imaginable. In theory even completely losing one commandand executing another one twice and then trying to interpret the outputsas if the command we intended to execute was actually executed and notthe other one is also possible. Frankly, I don't feel confident aboutproviding an exhaustive list of possible consequences.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()The function needs to check the minimal filehandle length before it canaccess the embedded filehandle.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()ath11k_mac_disable_peer_fixed_rate() is passed as the iterator toieee80211_iterate_stations_atomic(). Note in this case the iterator isrequired to be atomic, however ath11k_mac_disable_peer_fixed_rate() doesnot follow it as it might sleep. Consequently below warning is seen:BUG: sleeping function called from invalid context at wmi.c:304Call Trace: dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.coldChange to ieee80211_iterate_stations_mtx() to fix this issue.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix rcu_read_unlock() deadloop due to IRQ workDuring rcu_read_unlock_special(), if this happens during irq_exit(), wecan lockup if an IPI is issued. This is because the IPI itself triggersthe irq_exit() path causing a recursive lock up.This is precisely what Xiongfeng found when invoking a BPF program onthe trace_tick_stop() tracepoint As shown in the trace below. Fix bymanaging the irq_work state correctly.irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() /* a bpf prog is hooked on this trace point */ __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() /* will send a IPI to itself */ irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);A simple reproducer can also be obtained by doing the following intick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect ->defer_qs_iw_pending from data raceOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() isinvoked within an interrupts-disabled region of code [1], it will invokercu_read_unlock_special(), which uses an irq-work handler to force thesystem to notice when the RCU read-side critical section actually ends.That end won't happen until interrupts are enabled at the soonest.In some kernels, such as those booted with rcutree.use_softirq=y, theirq-work handler is used unconditionally.The per-CPU rcu_data structure's ->defer_qs_iw_pending field isupdated by the irq-work handler and is both read and updated byrcu_read_unlock_special(). This resulted in the following KCSAN splat:------------------------------------------------------------------------BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_specialread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30no locks held by irq_work/8/88.irq event stamp: 200272hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320hardirqs last disabled at (200271): [] __schedule+0x129/0xd70softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0softirqs last disabled at (0): [<0000000000000000>] 0x0------------------------------------------------------------------------The problem is that irq-work handlers run with interrupts enabled, whichmeans that rcu_preempt_deferred_qs_handler() could be interrupted,and that interrupt handler might contain an RCU read-side criticalsection, which might invoke rcu_read_unlock_special(). In the strictKCSAN mode of operation used by RCU, this constitutes a data race onthe ->defer_qs_iw_pending field.This commit therefore disables interrupts across the portion of thercu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pendingfield. This suffices because this handler is not a fast path.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/smaps: fix race between smaps_hugetlb_range and migrationsmaps_hugetlb_range() handles the pte without holdling ptl, and may beconcurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). The race is as follows.smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ONTo fix it, hold ptl lock in smaps_hugetlb_range().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 cluster segment descriptorsUAC3 class segment descriptors need to be verified whether their sizesmatch with the declared lengths and whether they fit with theallocated buffer sizes, too. Otherwise malicious firmware may lead tothe unexpected OOB accesses.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpagesEver since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),we have been doing this:static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size)[...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size);try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size);This means we've been sending oversized iov_iters and tcp_sendmsg callsfor a while. This has a been a benign bug because sendpage_ok() alwaysreturned true. With the recent slab allocator changes being slowlyintroduced into next (that disallow sendpage on large kmallocallocations), we have recently hit out-of-bounds crashes, due to slightdifferences in iov_iter behavior between the MSG_SPLICE_PAGES and"regular" copy paths:(MSG_SPLICE_PAGES)skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a "short" read(!MSG_SPLICE_PAGES)skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecsFix this by properly setting the iov_iter's byte count, plus sending thecorrect byte count to tcp_sendmsg_locked.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: remove refcounting in expectation dumpersSame pattern as previous patch: do not keep the expectation objectalive via refcount, only store a cookie value and then use thatas the skip hint for dump resumption.AFAICS this has the same issue as the one resolved in the conntrackdumper, when we do if (!refcount_inc_not_zero(&exp->use))to increment the refcount, there is a chance that exp == last, whichcauses a double-increment of the refcount and subsequent memory leak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limitThe following setup can trigger a WARNING in htb_activate due tothe condition: !cl->leaf.q->q.qlentc qdisc del dev lo roottc qdisc add dev lo root handle 1: htb default 1tc class add dev lo parent 1: classid 1:1 \ htb rate 64bittc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1bping -I lo -f -c1 -s64 -W0.001 127.0.0.1This is because the low memlimit leads to a low buffer_limit, whichcauses packet dropping. However, cake_enqueue still returnsNET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with anempty child qdisc. We should return NET_XMIT_CN when packets aredropped from the same tin and flow.I do not believe return value of NET_XMIT_CN is necessary for packetdrops in the case of ack filtering, as that is meant to optimizeperformance, not to signal congestion.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUMWhen performing Generic Segmentation Offload (GSO) on an IPv6 packet thatcontains extension headers, the kernel incorrectly requests checksum offloadif the egress device only advertises NETIF_F_IPV6_CSUM feature, which hasa strict contract: it supports checksum offload only for plain TCP or UDPover IPv6 and explicitly does not support packets with extension headers.The current GSO logic violates this contract by failing to disable the featurefor packets with extension headers, such as those used in GREoIPv6 tunnels.This violation results in the device being asked to perform an operationit cannot support, leading to a `skb_warn_bad_offload` warning and a collapseof network throughput. While device TSO/USO is correctly bypassed in favorof software GSO for these packets, the GSO stack must be explicitly told notto request checksum offload.Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4in gso_features_check if the IPv6 header contains extension headers to computechecksum in software.The exception is a BIG TCP extension, which, as stated in commit68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"):"The feature is only enabled on devices that support BIG TCP TSO.The header is only present for PF_PACKET taps like tcpdump,and not transmitted by physical devices."kernel log output (truncated):WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140...Call Trace: skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/0x150 __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50...skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0eskb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/hisilicon/hibmc: fix the hibmc loaded failed bugWhen hibmc loaded failed, the driver use hibmc_unload to free theresource, but the mutexes in mode.config are not init, which willaccess an NULL pointer. Just change goto statement to return, becausehibnc_hw_init() doesn't need to free anything.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix soft lockup in br_multicast_query_expired()When set multicast_query_interval to a large value, the local variable'time' in br_multicast_send_query() may overflow. If the time is smallerthan jiffies, the timer will expire immediately, and then call mod_timer()again, which creates a loop and may trigger the following soft lockupissue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 upThe multicast_startup_query_interval can also cause this issue. Similar tothe commit 99b40610956a ("net: bridge: mcast: add and enforce queryinterval minimum"), add check for the query interval maximum to fix thisissue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: prevent softlockup in jbd2_log_do_checkpoint()Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()periodically release j_list_lock after processing a batch of buffers toavoid long hold times on the j_list_lock. However, since both functionscontend for j_list_lock, the combined time spent waiting and processingcan be significant.jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() whenneed_resched() is true to avoid softlockups during prolonged operations.But jbd2_log_do_checkpoint() only exits its loop when need_resched() istrue, relying on potentially sleeping functions like __flush_batch() orwait_on_buffer() to trigger rescheduling. If those functions do not sleep,the kernel may hit a softlockup.watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017Workqueue: writeback wb_workfn (flush-7:2)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : native_queued_spin_lock_slowpath+0x358/0x418lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoidsoftlockup.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix configfs group list head handlingDoing a list_del() on the epf_group field of struct pci_epf_driver inpci_epf_remove_cfs() is not correct as this field is a list head, nota list entry. This list_del() call triggers a KASAN warning when anendpoint function driver which has a configfs attribute group is torndown:==================================================================BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONEHardware name: Radxa ROCK 5B (DT)Call trace:show_stack+0x2c/0x84 (C)dump_stack_lvl+0x70/0x98print_report+0x17c/0x538kasan_report+0xb8/0x190__asan_report_store8_noabort+0x20/0x2cpci_epf_remove_cfs+0x17c/0x198pci_epf_unregister_driver+0x18/0x30nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf]__arm64_sys_delete_module+0x264/0x424invoke_syscall+0x70/0x260el0_svc_common.constprop.0+0xac/0x230do_el0_svc+0x40/0x58el0_svc+0x48/0xdcel0t_64_sync_handler+0x10c/0x138el0t_64_sync+0x198/0x19c...Remove this incorrect list_del() call from pci_epf_remove_cfs().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: tegra: Use I/O memcpy to write to IRAMKasan crashes the kernel trying to check boundaries when using thenormal memcpy.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()If we find an unexpected generation for the extent buffer we are cloningat btrfs_copy_root(), we just WARN_ON() and don't error out and abort thetransaction, meaning we allow to persist metadata with an unexpectedgeneration. Instead of warning only, abort the transaction and return-EUCLEAN.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix unregister_netdev call order in macb_remove()When removing a macb device, the driver calls phy_exit() beforeunregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ...The warning happens because the PHY is being exited while the netdevis still registered. The correct order is to unregister the netdevbefore shutting down the PHY and cleaning up the MDIO bus.Fix this by moving unregister_netdev() ahead of phy_exit() inmacb_remove().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()A malicious HID device can trigger a slab out-of-bounds duringmt_report_fixup() by passing in report descriptor smaller than607 bytes. mt_report_fixup() attempts to patch byte offset 607of the descriptor with 0x25 by first checking if byte offset607 is 0x15 however it lacks bounds checks to verify if thedescriptor is big enough before conducting this check. Fixthis bug by ensuring the descriptor size is at least 608bytes before accessing it.Below is the KASAN splat after the out of bounds access happens:[ 13.671954] ==================================================================[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10[ 13.673297][ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04[ 13.673297] Call Trace:[ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80[ 13.673297] print_report+0xd1/0x660[ 13.673297] kasan_report+0xe5/0x120[ 13.673297] __asan_report_load1_noabort+0x18/0x20[ 13.673297] mt_report_fixup+0x103/0x110[ 13.673297] hid_open_report+0x1ef/0x810[ 13.673297] mt_probe+0x422/0x960[ 13.673297] hid_device_probe+0x2e2/0x6f0[ 13.673297] really_probe+0x1c6/0x6b0[ 13.673297] __driver_probe_device+0x24f/0x310[ 13.673297] driver_probe_device+0x4e/0x220[ 13.673297] __device_attach_driver+0x169/0x320[ 13.673297] bus_for_each_drv+0x11d/0x1b0[ 13.673297] __device_attach+0x1b8/0x3e0[ 13.673297] device_initial_probe+0x12/0x20[ 13.673297] bus_probe_device+0x13d/0x180[ 13.673297] device_add+0xe3a/0x1670[ 13.673297] hid_add_device+0x31d/0xa40[...]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()in ntrig_report_version(), hdev parameter passed from hid_probe().sending descriptor to /dev/uhid can make hdev->dev.parent->parent to nullif hdev->dev.parent->parent is null, usb_dev hasinvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returnedwhen usb_rcvctrlpipe() use usb_dev,it triggerpage fault error for address(0xffffffffffffff58)add null check logic to ntrig_report_version()before calling hid_to_usb_dev()
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix memory corruption when FW resources change during ifdownbnxt_set_dflt_rings() assumes that it is always called before any TC hasbeen created. So it doesn't take bp->num_tc into account and assumesthat it is always 0 or 1.In the FW resource or capability change scenario, the FW will returnflags in bnxt_hwrm_if_change() that will cause the driver toreinitialize and call bnxt_cancel_reservations(). This will lead tobnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tcmay be greater than 1. This will cause bp->tx_ring[] to be sized toosmall and cause memory corruption in bnxt_alloc_cp_rings().Fix it by properly scaling the TX rings by bp->num_tc in the codepaths mentioned above. Add 2 helper functions to determinebp->tx_nr_rings and bp->tx_nr_rings_per_tc.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: use array_index_nospec with indices that come from guestmin and dest_id are guest-controlled indices. Using array_index_nospec()after the bounds checks clamps these values to mitigate speculative executionside-channels.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: asus: fix UAF via HID_CLAIMED_INPUT validationAfter hid_hw_start() is called hidinput_connect() will eventually becalled to set up the device with the input layer since theHID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()all input and output reports are processed and corresponding hid_inputsare allocated and configured via hidinput_configure_usages(). Thisprocess involves slot tagging report fields and configuring usagesby setting relevant bits in the capability bitmaps. However it is possiblethat the capability bitmaps are not set at all leading to the subsequenthidinput_has_been_populated() check to fail leading to the freeing of thehid_input and the underlying input device.This becomes problematic because a malicious HID device like aASUS ROG N-Key keyboard can trigger the above scenario via aspecially crafted descriptor which then leads to a user-after-freewhen the name of the freed input device is written to later on afterhid_hw_start(). Below, report 93 intentionally utilises theHID_UP_UNDEFINED Usage Page which is skipped during usageconfiguration, leading to the frees.0x05, 0x0D, // Usage Page (Digitizer)0x09, 0x05, // Usage (Touch Pad)0xA1, 0x01, // Collection (Application)0x85, 0x0D, // Report ID (13)0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)0x09, 0xC5, // Usage (0xC5)0x15, 0x00, // Logical Minimum (0)0x26, 0xFF, 0x00, // Logical Maximum (255)0x75, 0x08, // Report Size (8)0x95, 0x04, // Report Count (4)0xB1, 0x02, // Feature (Data,Var,Abs)0x85, 0x5D, // Report ID (93)0x06, 0x00, 0x00, // Usage Page (Undefined)0x09, 0x01, // Usage (0x01)0x15, 0x00, // Logical Minimum (0)0x26, 0xFF, 0x00, // Logical Maximum (255)0x75, 0x08, // Report Size (8)0x95, 0x1B, // Report Count (27)0x81, 0x02, // Input (Data,Var,Abs)0xC0, // End CollectionBelow is the KASAN splat after triggering the UAF:[ 21.672709] ==================================================================[ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80[ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54[ 21.673700][ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)[ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014[ 21.673700] Call Trace:[ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80[ 21.673700] print_report+0xd1/0x660[ 21.673700] kasan_report+0xe5/0x120[ 21.673700] __asan_report_store8_noabort+0x1b/0x30[ 21.673700] asus_probe+0xeeb/0xf80[ 21.673700] hid_device_probe+0x2ee/0x700[ 21.673700] really_probe+0x1c6/0x6b0[ 21.673700] __driver_probe_device+0x24f/0x310[ 21.673700] driver_probe_device+0x4e/0x220[...][ 21.673700][ 21.673700] Allocated by task 54:[ 21.673700] kasan_save_stack+0x3d/0x60[ 21.673700] kasan_save_track+0x18/0x40[ 21.673700] kasan_save_alloc_info+0x3b/0x50[ 21.673700] __kasan_kmalloc+0x9c/0xa0[ 21.673700] __kmalloc_cache_noprof+0x139/0x340[ 21.673700] input_allocate_device+0x44/0x370[ 21.673700] hidinput_connect+0xcb6/0x2630[ 21.673700] hid_connect+0xf74/0x1d60[ 21.673700] hid_hw_start+0x8c/0x110[ 21.673700] asus_probe+0x5a3/0xf80[ 21.673700] hid_device_probe+0x2ee/0x700[ 21.673700] really_probe+0x1c6/0x6b0[ 21.673700] __driver_probe_device+0x24f/0x310[ 21.673700] driver_probe_device+0x4e/0x220[...][ 21.673700][ 21.673700] Freed by task 54:[ 21.673700] kasan_save_stack+0x3d/0x60[ 21.673700] kasan_save_track+0x18/0x40[ 21.673700] kasan_save_free_info+0x3f/0x60[ 21.673700] __kasan_slab_free+0x3c/0x50[ 21.673700] kfre---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().syzbot reported the splat below. [0]When atmtcp_v_open() or atmtcp_v_close() is called via connect()or close(), atmtcp_send_control() is called to send an in-kernelspecial message.The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.The notable thing is struct atmtcp_control is uAPI but has aspace for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;The special message is processed in atmtcp_recv_control() calledfrom atmtcp_c_send().atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()The problem is sendmsg() does not validate the message length anduserspace can abuse atmtcp_recv_control() to overwrite any kptrby atmtcp_control.Let's add a new ->pre_send() hook to validate messages from sendmsg().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTIKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4cRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068cRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0ddR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffffFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f8d7e96a4a9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10acR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix lockdep assertion on sync reset unload eventFix lockdep assertion triggered during sync reset unload event. When thesync reset flow is initiated using the devlink reload fw_activateoption, the PF already holds the devlink lock while handling unloadevent. In this case, delegate sync reset unload event handling back tothe devlink callback process to avoid double-locking and resolve thelockdep warning.Kernel log:WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40[...]Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: do not propagate ENODATA disk errors into xattr codeENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;namely, that the requested attribute name could not be found.However, a medium error from disk may also return ENODATA. At best,this medium error may escape to userspace as "attribute not found"when in fact it's an IO (disk) error.At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; }because an ENODATA/ENOATTR error from disk leaves us with a null bp,and the xfs_trans_brelse will then null-deref it.As discussed on the list, we really need to modify the lower levelIO functions to trap all disk errors and ensure that we don't letunique errors like this leak up into higher xfs functions - manylike this should be remapped to EIO.However, this patch directly addresses a reported bug in the xattrcode, and should be safe to backport to stable kernels. A larger-scopepatch to handle more unique errors at lower levels can follow later.(Note, prior to 07120f1abdff we did not oops, but we did return thewrong error code to userspace.)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix OOB read/write in network-coding decodebatadv_nc_skb_decode_packet() trusts coded_len and checks only againstskb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducingpayload headroom, and the source skb length is not verified, allowing anout-of-bounds read and a small out-of-bounds write.Validate that coded_len fits within the payload area of both destinationand source sk_buffs before XORing.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: prevent release journal inode after journal shutdownBefore calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has alreadybeen executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reachesjbd2_journal_release_jbd_inode().ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal,Adding osb->journal checks will prevent null-ptr-deref during the aboveexecution path.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: move page table sync declarations to linux/pgtable.hDuring our internal testing, we started observing intermittent bootfailures when the machine uses 4-level paging and has a large amount ofpersistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (structpage array) when the vmemmap region spans two PGD entries, because the newPGD entry is only installed in init_mm.pgd, but not in the page tables ofother tasks.And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap);In the normal path, vmemmap_populate() in arch/x86/mm/init_64.csynchronizes the top level page table (See commit 9b861528a801 ("x86-64,mem: Update all PGDs for direct mapping and vmemmap mapping changes")) sothat all tasks in the system can see the new vmemmap area.However, when vmemmap_can_optimize() returns true, the optimized pathskips synchronization of top-level page tables. This is becausevmemmap_populate_compound_pages() is implemented in core MM code, whichdoes not handle synchronization of the top-level page tables. Instead,the core MM has historically relied on each architecture to perform thissynchronization manually.We're not the first party to encounter a crash caused by not-sync'd toplevel page tables: earlier this year, Gwan-gyeong Mun attempted to addressthe issue [1] [2] after hitting a kernel panic when x86 code accessed thevmemmap area before the corresponding top-level entries were synced. Atthat time, the issue was believed to be triggered only when struct pagewas enlarged for debugging purposes, and the patch did not get furtherupdates.It turns out that current approach of relying on each arch to handle thepage table sync manually is fragile because 1) it's easy to forget to syncthe top level page table, and 2) it's also easy to overlook that thekernel should not access the vmemmap and direct mapping areas before thesync.# The solution: Make page table sync more code robust and harder to missTo address this, Dave Hansen suggested [3] [4] introducing{pgd,p4d}_populate_kernel() for updating kernel portion of the page tablesand allow each architecture to explicitly perform synchronization wheninstalling top-level entries. With this approach, we no longer need toworry about missing the sync step, reducing the risk of futureregressions.The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used byvmalloc and ioremap to synchronize page tables.pgd_populate_kernel() looks like this:static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d){ pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr);}It is worth noting that vmalloc() and apply_to_range() carefullysynchronizes page tables by calling p*d_alloc_track() andarch_sync_kernel_mappings(), and thus they are not affected by---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensurepage tables are properly synchronized when calling p*d_populate_kernel().For 5-level paging, synchronization is performed viapgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, sosynchronization is instead performed at the P4D level viap4d_populate_kernel().This fixes intermittent boot failures on systems using 4-level paging anda large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmapbefore sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()In __iodyn_find_io_region(), pcmcia_make_resource() is assigned tores and used in pci_bus_alloc_resource(). There is a dereference of resin pci_bus_alloc_resource(), which could lead to a NULL pointerdereference on failure of pcmcia_make_resource().Fix this bug by adding a check of res.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix memory leak in pad_compress_skbIf alloc_skb() fails in pad_compress_skb(), it returns NULL withoutreleasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop;drop: kfree_skb(skb);When pad_compress_skb() returns NULL, the reference to the old skb islost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.Align pad_compress_skb() semantics with realloc(): only free the oldskb if allocation and compression succeed. At the call site, use thenew_skb variable so the original skb is not lost when pad_compress_skb()fails.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it wouldlead to memory corruption so add some bounds checking.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objectsWhen the "proxy" option is enabled on a VXLAN device, the device willsuppress ARP requests and IPv6 Neighbor Solicitation messages if it isable to reply on behalf of the remote host. That is, if a matching andvalid neighbor entry is configured on the VXLAN device whose MAC addressis not behind the "any" remote (0.0.0.0 / ::).The code currently assumes that the FDB entry for the neighbor's MACaddress points to a valid remote destination, but this is incorrect ifthe entry is associated with an FDB nexthop group. This can result in aNPD [1][3] which can be reproduced using [2][4].Fix by checking that the remote destination exists before dereferencingit.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_xmit+0xb58/0x15f0[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3[3]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014RIP: 0010:vxlan_xmit+0x803/0x1600[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f383422ec77[4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD when refreshing an FDB entry with a nexthop objectVXLAN FDB entries can point to either a remote destination or an FDBnexthop group. The latter is usually used in EVPN deployments wherelearning is disabled.However, when learning is enabled, an incoming packet might try torefresh an FDB entry that points to an FDB nexthop group and thereforedoes not have a remote. Such packets should be dropped, but they areonly dropped after dereferencing the non-existent remote, resulting in aNPD [1] which can be reproduced using [2].Fix by dropping such packets earlier. Remove the misleading comment fromfirst_remote_rcu().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_snoop+0x98/0x1e0[...]Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix potential invalid access when MAC list is emptylist_first_entry() never returns NULL - if the list is empty, it stillreturns a pointer to an invalid object, leading to potential invalidmemory access when dereferenced.Fix this by using list_first_entry_or_null instead of list_first_entry.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix NULL access of tx->in_use in ice_ll_ts_intrRecent versions of the E810 firmware have support for an extra interrupt tohandle report of the "low latency" Tx timestamps coming from thespecialized low latency firmware interface. Instead of polling theregisters, software can wait until the low latency interrupt is fired.This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, asit uses the same "ready" bitmap to track which Tx timestamps complete.Unfortunately, the ice_ll_ts_intr() function does not check if thetracker is initialized before its first access. This results in NULLdereference or use-after-free bugs similar to the issues fixed in theice_ptp_ts_irq() function.Fix this by only checking the in_use bitmap (and other fields) if thetracker is marked as initialized. The reset flow will clear the init fieldunder lock before it tears the tracker down, thus preventing anyuse-after-free or NULL access.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()BUG: kernel NULL pointer dereference, address: 00000000000002ecPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONETainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014Workqueue: smc_hs_wq smc_listen_work [smc]RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]...Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer.As a result, the problem occurs. Null pointer detection is added toprevent problems.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdogThe ptp_ocp_detach() only shuts down the watchdog timer if it ispending. However, if the timer handler is already running, thetimer_delete_sync() is not called. This leads to race conditionswhere the devlink that contains the ptp_ocp is deallocated whilethe timer handler is still accessing it, resulting in use-after-freebugs. The following details one of the race scenarios.(thread 1) | (thread 2)ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //useResolve this by unconditionally calling timer_delete_sync() to ensurethe timer is reliably deactivated, preventing any access after free.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()syzbot reported the splat below without a repro.In the splat, a single thread calling bt_accept_dequeue() freed skand touched it after that.The root cause would be the racy l2cap_sock_cleanup_listen() calladded by the cited commit.bt_accept_dequeue() is called under lock_sock() except forl2cap_sock_release().Two threads could see the same socket during the list iterationin bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAFDepending on the timing, the other thread could show up in the"Freed by task" part.Let's call l2cap_sock_cleanup_listen() under lock_sock() inl2cap_sock_release().[0]:BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 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+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2accf8ebe9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166fR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609cR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: vhci: Prevent use-after-free by removing debugfs files earlyMove the creation of debugfs files into a dedicated function, and ensurethey are explicitly removed during vhci_release(), before associateddata structures are freed.Previously, debugfs files such as "force_suspend", "force_wakeup", andothers were created under hdev->debugfs but not removed invhci_release(). Since vhci_release() frees the backing vhci_datastructure, any access to these files after release would result inuse-after-free errors.Although hdev->debugfs is later freed in hci_release_dev(), user canaccess files after vhci_data is freed but before hdev->debugfs isreleased.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info workThe brcmf_btcoex_detach() only shuts down the btcoex timer, if theflag timer_on is false. However, the brcmf_btcoex_timerfunc(), whichruns as timer handler, sets timer_on to false. This creates criticalrace conditions:1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()is executing, it may observe timer_on as false and skip the call totimer_shutdown_sync().2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_infoworker after the cancel_work_sync() has been executed, resulting inuse-after-free bugs.The use-after-free bugs occur in two distinct scenarios, depending onthe timing of when the brcmf_btcoex_info struct is freed relative tothe execution of its worker thread.Scenario 1: Freed before the worker is scheduledThe brcmf_btcoex_info is deallocated before the worker is scheduled.A race condition can occur when schedule_work(&bt_local->work) iscalled after the target memory has been freed. The sequence of eventsis detailed below:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USEScenario 2: Freed after the worker is scheduledThe brcmf_btcoex_info is freed after the worker has been scheduledbut before or during its execution. In this case, statements withinthe brcmf_btcoex_handler() - such as the container_of macro andsubsequent dereferences of the brcmf_btcoex_info object will causea use-after-free access. The following timeline illustrates thisscenario:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ |To resolve the race conditions, drop the conditional check and calltimer_shutdown_sync() directly. It can deactivate the timer reliably,regardless of its current state. Once stopped, the timer_on state isthen set to false.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix use-after-free in cmp_bss()Following bss_free() quirk introduced in commit 776b3580178f("cfg80211: track hidden SSID networks properly"), adjustcfg80211_update_known_bss() to free the last beacon frameelements only if they're not shared via the corresponding'hidden_beacon_bss' pointer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: fix NULL pointer dereference in tee_shm_puttee_shm_put have NULL pointer dereference:__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crashAdd check in tee_shm_put to fix it.panic log:Unable to handle kernel paging request at virtual address 0000000000100ccaMem abort info:ESR = 0x0000000096000004EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x04: level 0 translation faultData abort info:ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----6.6.0-39-generic #38Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.010/26/2022pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : tee_shm_put+0x24/0x188lr : tee_shm_free+0x14/0x28sp : ffff001f98f9faf0x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffffx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0cx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100ccaCall trace:tee_shm_put+0x24/0x188tee_shm_free+0x14/0x28__optee_disable_shm_cache+0xa8/0x108optee_shutdown+0x28/0x38platform_shutdown+0x28/0x40device_shutdown+0x144/0x2b0kernel_power_off+0x3c/0x80hibernate+0x35c/0x388state_store+0x64/0x80kobj_attr_store+0x14/0x28sysfs_kf_write+0x48/0x60kernfs_fop_write_iter+0x128/0x1c0vfs_write+0x270/0x370ksys_write+0x6c/0x100__arm64_sys_write+0x20/0x30invoke_syscall+0x4c/0x120el0_svc_common.constprop.0+0x44/0xf0do_el0_svc+0x24/0x38el0_svc+0x24/0x88el0t_64_sync_handler+0x134/0x150el0t_64_sync+0x14c/0x15
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Fix memory allocation size for queue_priority_mapFix a critical memory allocation bug in edma_setup_from_hw() wherequeue_priority_map was allocated with insufficient memory. The codedeclared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),but allocated memory using sizeof(s8) instead of the correct size.This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i;The bug manifested as kernel crashes with "Oops - undefined instruction"on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as thememory corruption triggered kernel hardening features on Clang.Change the allocation to use sizeof(*queue_priority_map) whichautomatically gets the correct size for the 2D array structure.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix double free in idxd_setup_wqs()The clean up in idxd_setup_wqs() has had a couple bugs because the errorhandling is a bit subtle. It's simpler to just re-write it in a cleanerway. The issues here are:1) If "idxd->max_wqs" is <= 0 then we call put_device(conf_dev) when "conf_dev" hasn't been initialized.2) If kzalloc_node() fails then again "conf_dev" is invalid. It's either uninitialized or it points to the "conf_dev" from the previous iteration so it leads to a double free.It's better to free partial loop iterations within the loop and thenthe unwinding at the end can handle whole loop iterations. I alsorenamed the labels to describe what the goto does and not where the gotowas located.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Remove improper idxd_freeThe call to idxd_free() introduces a duplicate put_device() leading to areference count underflow:refcount_t: underflow; use-after-free.WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110...Call Trace: idxd_remove+0xe4/0x120 [idxd] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x197/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 idxd_exit_module+0x34/0x7a0 [idxd] __do_sys_delete_module.constprop.0+0x183/0x280 do_syscall_64+0x54/0xd70 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe idxd_unregister_devices() which is invoked at the very beginning ofidxd_remove(), already takes care of the necessary put_device() through thefollowing call path:idxd_unregister_devices() -> device_unregister() -> put_device()In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() maytrigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() iscalled immediately after, it can result in a use-after-free.Remove the improper idxd_free() to avoid both the refcount underflow andpotential memory corruption during module unload.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKBcan_put_echo_skb() takes ownership of the SKB and it may be freedduring or after the call.However, xilinx_can xcan_write_frame() keeps using SKB after the call.Fix that by only calling can_put_echo_skb() after the code is donetouching the SKB.The tx_lock is held for the entire xcan_write_frame() execution andalso on the can_get_echo_skb() side so the order of operations does notmatter.An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skbmemory") did not move the can_put_echo_skb() call far enough.[mkl: add "commit" in front of sha1 in patch description][mkl: fix indention]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernfs: Fix UAF in polling when open file is releasedA use-after-free (UAF) vulnerability was identified in the PSI (PressureStall Information) monitoring mechanism:BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140Read of size 8 at addr ffff3de3d50bd308 by task systemd/1psi_trigger_poll+0x3c/0x140cgroup_pressure_poll+0x70/0xa0cgroup_file_poll+0x8c/0x100kernfs_fop_poll+0x11c/0x1c0ep_item_poll.isra.0+0x188/0x2c0Allocated by task 1:cgroup_file_open+0x88/0x388kernfs_fop_open+0x73c/0xaf0do_dentry_open+0x5fc/0x1200vfs_open+0xa0/0x3f0do_open+0x7e8/0xd08path_openat+0x2fc/0x6b0do_filp_open+0x174/0x368Freed by task 8462:cgroup_file_release+0x130/0x1f8kernfs_drain_open_files+0x17c/0x440kernfs_drain+0x2dc/0x360kernfs_show+0x1b8/0x288cgroup_file_show+0x150/0x268cgroup_pressure_write+0x1dc/0x340cgroup_file_write+0x274/0x548Reproduction Steps:1. Open test/cpu.pressure and establish epoll monitoring2. Disable monitoring: echo 0 > test/cgroup.pressure3. Re-enable monitoring: echo 1 > test/cgroup.pressureThe race condition occurs because:1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files()2. While epoll still holds reference to the file and continues polling3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->privepolling disable/enable cgroup.pressurefd=open(cpu.pressure)while(1)...epoll_waitkernfs_fop_pollkernfs_get_active = true echo 0 > cgroup.pressure... cgroup_file_show kernfs_show // inactive kn kernfs_drain_open_files cft->release(of); kfree(ctx); ...kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn);kernfs_fop_pollkernfs_get_active = truecgroup_file_pollpsi_trigger_poll// UAF...end: close(fd)To address this issue, introduce kernfs_get_active_of() for kernfs openfiles to obtain active references. This function will fail if the open filehas been released. Replace kernfs_get_active() with kernfs_get_active_of()to prevent further operations on released file descriptors.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: fix potential OF node use-after-freeThe for_each_child_of_node() helper drops the reference it takes to eachnode as it iterates over children and an explicit of_node_put() is onlyneeded when exiting the loop early.Drop the recently introduced bogus additional reference count decrementat each iteration that could potentially lead to a use-after-free.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix recursive semaphore deadlock in fiemap callsyzbot detected a OCFS2 hang due to a recursive semaphore on aFS_IOC_FIEMAP of the extent list on a specially crafted mmap file.context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41RSP: 0018:ffffc9000403f950 EFLAGS: 00050256RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5f13850fd9RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03bocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (sincev2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read theextent list of this running mmap executable. The user supplied buffer tohold the fiemap information page faults calling ocfs2_page_mkwrite() whichwill take a write lock (since v2.6.27-38-g00dc417fa3e7) of the samesemaphore. This recursive semaphore will hold filesystem locks and causesa hang of the fileystem.The ip_alloc_sem protects the inode extent list and size. Release theread semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlockon the last extent but simplifies the error path.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched: Fix sched_numa_find_nth_cpu() if mask offlinesched_numa_find_nth_cpu() uses a bsearch to look for the 'closest'CPU in sched_domains_numa_masks and given cpus mask. However theymight not intersect if all CPUs in the cpus mask are offline. bsearchwill return NULL in that case, bail out instead of dereferencing abogus pointer.The previous behaviour lead to this bug when using maxcpus=4 on anrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000[ 1.423635] Mem abort info:[ 1.423889] ESR = 0x0000000096000006[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits[ 1.424715] SET = 0, FnV = 0[ 1.424995] EA = 0, S1PTW = 0[ 1.425279] FSC = 0x06: level 2 translation fault[ 1.425735] Data abort info:[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP[ 1.429525] Modules linked in:[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488[ 1.432543] sp : ffffffc084e1b960[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68[ 1.439332] Call trace:[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)[ 1.440016] smp_call_function_any+0xc8/0xd0[ 1.440416] armv8_pmu_init+0x58/0x27c[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8[ 1.441603] armv8_pmu_device_probe+0x1c/0x28[ 1.442007] platform_probe+0x5c/0xac[ 1.442347] really_probe+0xbc/0x298[ 1.442683] __driver_probe_device+0x78/0x12c[ 1.443087] driver_probe_device+0xdc/0x160[ 1.443475] __driver_attach+0x94/0x19c[ 1.443833] bus_for_each_dev+0x74/0xd4[ 1.444190] driver_attach+0x24/0x30[ 1.444525] bus_add_driver+0xe4/0x208[ 1.444874] driver_register+0x60/0x128[ 1.445233] __platform_driver_register+0x24/0x30[ 1.445662] armv8_pmu_driver_init+0x28/0x4c[ 1.446059] do_one_initcall+0x44/0x25c[ 1.446416] kernel_init_freeable+0x1dc/0x3bc[ 1.446820] kernel_init+0x20/0x1d8[ 1.447151] ret_from_fork+0x10/0x20[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)[ 1.448040] ---[ end trace 0000000000000000 ]---[ 1.448483] note: swapper/0[1] exited with preempt_count 1[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b[ 1.449741] SMP: stopping secondary CPUs[ 1.450105] Kernel Offset: disabled[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b[ ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: avoid accessing metadata when pointer is invalid in object_err()object_err() reports details of an object for further debugging, such asthe freelist pointer, redzone, etc. However, if the pointer is invalid,attempting to access object metadata can lead to a crash since it doesnot point to a valid object.One known path to the crash is when alloc_consistency_checks()determines the pointer to the allocated object is invalid because of afreelist corruption, and calls object_err() to report it. The debug codeshould report and handle the corruption gracefully and not crash in theprocess.In case the pointer is NULL or check_valid_pointer() returns false forthe pointer, only print the pointer value and skip accessing metadata.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC bufferAvoid below overlapping mappings by using a contiguousnon-cacheable buffer.[ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,overlapping mappings aren't supported[ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300[ 4.097071] Modules linked in:[ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1[ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)[ 4.118824] Workqueue: events_unbound deferred_probe_work_func[ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.131624] pc : add_dma_entry+0x23c/0x300[ 4.135658] lr : add_dma_entry+0x23c/0x300[ 4.139792] sp : ffff800009dbb490[ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000[ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8[ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20[ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006[ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e[ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec[ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58[ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000[ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000[ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40[ 4.214185] Call trace:[ 4.216605] add_dma_entry+0x23c/0x300[ 4.220338] debug_dma_map_sg+0x198/0x350[ 4.224373] __dma_map_sg_attrs+0xa0/0x110[ 4.228411] dma_map_sg_attrs+0x10/0x2c[ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc[ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174[ 4.242127] nand_read_oob+0x1d4/0x8e0[ 4.245861] mtd_read_oob_std+0x58/0x84[ 4.249596] mtd_read_oob+0x90/0x150[ 4.253231] mtd_read+0x68/0xac
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pcmcia: Add error handling for add_interval() in do_validate_mem()In the do_validate_mem(), the call to add_interval() does nothandle errors. If kmalloc() fails in add_interval(), it couldresult in a null pointer being inserted into the linked list,leading to illegal memory access when sub_interval() is callednext.This patch adds an error handling for the add_interval(). Ifadd_interval() returns an error, the function will return earlywith the error code.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: implement NETDEV_UNREGISTER notification handlersyzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2problem, for j1939 protocol did not have NETDEV_UNREGISTER notificationhandler for undoing changes made by j1939_sk_bind().Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destructcallback") expects that a call to j1939_priv_put() can be unconditionallydelayed until j1939_sk_sock_destruct() is called. But we need to callj1939_priv_put() against an extra ref held by j1939_sk_bind() call(as a part of undoing changes made by j1939_sk_bind()) as soon asNETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()is called via j1939_sk_release()). Otherwise, the extra ref on "structj1939_priv" held by j1939_sk_bind() call prevents "struct net_device" fromdropping the usage count to 1; making it impossible forunregister_netdevice() to continue.[mkl: remove space in front of label]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: anx7625: Fix NULL pointer dereference with early IRQIf the interrupt occurs before resource initialization is complete, theinterrupt handler/worker may access uninitialized data such as the I2Ctcpc_client device, potentially leading to NULL pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failedIf earlier opening of source graph fails (e.g. ADSP rejects due toincorrect audioreach topology), the graph is closed and"dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sinkgraph continues though and next call to q6apm_lpass_dai_prepare()receives dai_data->graph[dai->id]=NULL leading to NULL pointerexception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),which does not ensure that the delayed work item synctstamp_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_workremains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().Furthermore, the synctstamp_work is cyclic, the likelihood of triggeringthe bug is nonnegligible.A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAFThis is confirmed by a KASAN report:BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800aa09a18 by task bash/136...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled before the otx2_ptp isdeallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the OcteonTX2 PCI device in QEMU and introducedartificial delays within the otx2_sync_tstamp() function to increase thelikelihood of triggering the bug.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: make sure to abort the stream if headers are bogusNormally we wait for the socket to buffer up the whole recordbefore we service it. If the socket has a tiny buffer, however,we read out the data sooner, to prevent connection stalls.Make sure that we abort the connection when we find out latethat the record is actually invalid. Retrying the parsing isfine in itself but since we copy some more data each timebefore we parse we can overflow the allocated skb space.Constructing a scenario in which we're under pressure withoutenough data in the socket to parse the length upfront is quitehard. syzbot figured out a way to do this by serving us the headerin small OOB sends, and then filling in the recvbuf with a largenormal send.Make sure that tls_rx_msg_size() aborts strp, if we reachan invalid record there's really no way to recover.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn->state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 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:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the mcba_usb driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, mcba_usb_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN frame.This can result in a buffer overflow. The driver will consume cf->lenas-is with no further checks on these lines: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc);Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the sun4i_can driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, sun4ican_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN frame.This can result in a buffer overflow. The driver will consume cf->lenas-is with no further checks on this line: dlc = cf->len;Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs acouple line below when doing: for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + (dreg + i * 4));Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the sun4i_can driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, hi3110_hard_start_xmit() receives a CAN XL frame which it isnot able to correctly handle and will thus misinterpret it as a CANframe. The driver will consume frame->len as-is with no furtherchecks.This can result in a buffer overflow later on in hi3110_hw_tx() onthis line: memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);Here, frame->len corresponds to the flags field of the CAN XL frame.In our previous example, we set canxl_frame->flags to 0xff. Becausethe maximum expected length is 8, a buffer overflow of 247 bytesoccurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the etas_es58x driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, es58x_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN(FD)frame.This can result in a buffer overflow. For example, using the es581.4variant, the frame will be dispatched to es581_4_tx_can_msg(), gothrough the last check at the beginning of this function: if (can_is_canfd_skb(skb)) return -EMSGSIZE;and reach this line: memcpy(tx_can_msg->data, cf->data, cf->len);Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU orCANFD_MTU (depending on the device capabilities). By fixing the rootcause, this prevents the buffer overflow.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()If ab->fw.m3_data points to data, then fw pointer remains null.Further, if m3_mem is not allocated, then fw is dereferenced to bepassed to ath11k_err function.Replace fw->size by m3_len.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: fix races with imon_disconnect()Syzbot reports a KASAN issue as below:BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106print_address_description mm/kasan/report.c:317 [inline]print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433kasan_report+0xb1/0x1e0 mm/kasan/report.c:495__create_pipe include/linux/usb.h:1945 [inline]send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991vfs_write+0x2d7/0xdd0 fs/read_write.c:576ksys_write+0x127/0x250 fs/read_write.c:631do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdThe iMON driver improperly releases the usb_device reference inimon_disconnect without coordinating with active users of thedevice.Specifically, the fields usbdev_intf0 and usbdev_intf1 are notprotected by the users counter (ictx->users). During probe,imon_init_intf0 or imon_init_intf1 increments the usb_devicereference count depending on the interface. However, duringdisconnect, usb_put_dev is called unconditionally, regardless ofactual usage.As a result, if vfd_write or other operations are still inprogress after disconnect, this can lead to a use-after-free ofthe usb_device pointer.Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1)...while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAFGuard access to usbdev_intf0 and usbdev_intf1 after disconnect bychecking ictx->disconnected in all writer paths. Add early returnwith -ENODEV in send_packet(), vfd_write(), lcd_write() anddisplay_open() if the device is no longer present.Set and read ictx->disconnected under ictx->lock to ensure memorysynchronization. Acquire the lock in imon_disconnect() before settingthe flag to synchronize with any ongoing operations.Ensure writers exit early and safely after disconnect before the USBcore proceeds with cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: tuner: xc5000: Fix use-after-free in xc5000_releaseThe original code uses cancel_delayed_work() in xc5000_release(), whichdoes not guarantee that the delayed work item timer_sleep has fullycompleted if it was already running. This leads to use-after-free scenarioswhere xc5000_release() may free the xc5000_priv while timer_sleep is stillactive and attempts to dereference the xc5000_priv.A typical race condition is illustrated below:CPU 0 (release thread) | CPU 1 (delayed work callback)xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the timer_sleep is properly canceled before the xc5000_priv memoryis deallocated.A deadlock concern was considered: xc5000_release() is called in a processcontext and is not holding any locks that the timer_sleep work item mightalso need. Therefore, the use of the _sync() variant is safe here.This bug was initially identified through static analysis.[hverkuil: fix typo in Subject: tunner -> tuner]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probeThe state->timer is a cyclic timer that schedules work_i2c_poll anddelayed_work_enable_hotplug, while rearming itself. Using timer_delete()fails to guarantee the timer isn't still running when destroyed, similarlycancel_delayed_work() cannot ensure delayed_work_enable_hotplug hasterminated if already executing. During probe failure after timerinitialization, these may continue running as orphans and reference thealready-freed tc358743_state object through tc358743_irq_poll_timer.The following is the trace captured by KASAN.BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace timer_delete() with timer_delete_sync() and cancel_delayed_work()with cancel_delayed_work_sync() to ensure proper termination of timer andwork items before resource cleanup.This bug was initially identified through static analysis. For reproductionand testing, I created a functional emulation of the tc358743 device via akernel module and introduced faults through the debugfs interface.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_removeThe original code uses cancel_delayed_work() in flexcop_pci_remove(), whichdoes not guarantee that the delayed work item irq_check_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere flexcop_pci_remove() may free the flexcop_device while irq_check_workis still active and attempts to dereference the device.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAFThis is confirmed by a KASAN report:==================================================================BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff8880093aa8c8 by task bash/135...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executing delayedwork has finished before the device memory is deallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the B2C2 FlexCop PCI device in QEMU and introducedartificial delays within the flexcop_pci_irq_check_work() function toincrease the likelihood of triggering the bug.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_freeThe previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly atremoval") patched a UAF issue caused by the error timer.However, because the error timer kill added in this patch occurs after theendpoint delete, a race condition to UAF still occurs, albeit rarely.Additionally, since kill-cleanup for urb is also missing, freed memory canbe accessed in interrupt context related to urb, which can cause UAF.Therefore, to prevent this, error timer and urb must be killed beforefreeing the heap memory.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries toaccess already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258It is a consequence of a race between the waiting and the signaling sideof the completion: Waiting thread Completing threadrtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix potential null pointer dereference in afs_put_serverafs_put_server() accessed server->debug_id before the NULL check, whichcould lead to a null pointer dereference. Move the debug_id assignment,ensuring we never dereference a NULL server pointer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: Fix null dereference in hdmi teardownpci_set_drvdata sets the value of pdev->driver_data to NULL,after which the driver_data obtained from the same dev isdereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev isextracted from it. To prevent this, swap these calls.Found by Linux Verification Center (linuxtesting.org) with Svacer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: audioreach: fix potential null pointer dereferenceIt is possible that the topology parsing functionaudioreach_widget_load_module_common() could return NULL or an errorpointer. Add missing NULL check so that we do not dereference it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: Check return value of platform_get_resource()platform_get_resource() returns NULL in case of failure, so check itsreturn value and propagate the error in order to prevent NULL pointerdereference.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: fix possible map leak in fastrpc_put_argscopy_to_user() failure would cause an early return without cleaning upthe fdlist, which has been updated by the DSP. This could lead to mapleak. Fix this by redirecting to a cleanup path on failure, ensuringthat all mapped buffers are properly released before returning.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't validSkip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIPisn't valid, e.g. because KVM is running with nrips=false. SVM mustdecode and emulate to skip the instruction if the CPU doesn't provide thenext RIP, and getting the instruction bytes to decode requires readingguest memory. Reading guest memory through the emulator can fault, i.e.can sleep, which is disallowed since the fastpath handlers run with IRQsdisabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but withdifferent justification (KVM now grabs SRCU when skipping the instructionfor other reasons).
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/ksm: fix flag-dropping behavior in ksm_madvisesyzkaller discovered the following crash: (kernel BUG)[ 44.607039] ------------[ cut here ]------------[ 44.607422] kernel BUG at mm/userfaultfd.c:2067![ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460[ 44.617726] Call Trace:[ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0[ 44.620976] __fput+0x3f9/0xb60[ 44.621240] fput_close_sync+0x110/0x210[ 44.622222] __x64_sys_close+0x8f/0x120[ 44.622530] do_syscall_64+0x5b/0x2f0[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 44.623244] RIP: 0033:0x7f365bb3f227Kernel panics because it detects UFFD inconsistency duringuserfaultfd_release_all(). Specifically, a VMA which has a valid pointerto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.The inconsistency is caused in ksm_madvise(): when user calls madvise()with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,it accidentally clears all flags stored in the upper 32 bits ofvma->vm_flags.Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int andint are 32-bit wide. This setup causes the following mishap during the &=~VM_MERGEABLE assignment.VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is thenpromoted to unsigned long before the & operation. This promotion fillsupper 32 bits with leading 0s, as we're doing unsigned conversion (andeven for a signed conversion, this wouldn't help as the leading bit is 0).& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffffinstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clearsthe upper 32-bits of its value.Fix it by changing `VM_MERGEABLE` constant to unsigned long, using theBIT() macro.Note: other VM_* flags are not affected: This only happens to theVM_MERGEABLE flag, as the other VM_* flags are all constants of type intand after ~ operation, they end up with leading 1 and are thus convertedto unsigned long with leading 1s.Note 2:After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this isno longer a kernel BUG, but a WARNING at the same place:[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067but the root-cause (flag-drop) remains the same.[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Let userspace take care of interrupt maskRemove the logic to set interrupt mask by default in uio_hv_genericdriver as the interrupt mask value is supposed to be controlledcompletely by the user space. If the mask bit gets changedby the driver, concurrently with user mode operating on the ring,the mask bit may be set when it is supposed to be clear, and theuser-mode driver will miss an interrupt which will cause a hang.For eg- when the driver sets inbound ring buffer interrupt mask to 1,the host does not interrupt the guest on the UIO VMBus channel.However, setting the mask does not prevent the host from putting amessage in the inbound ring buffer. So let's assume that happens,the host puts a message into the ring buffer but does not interrupt.Subsequently, the user space code in the guest sets the inbound ringbuffer interrupt mask to 0, saying "Hey, I'm ready for interrupts".User space code then calls pread() to wait for an interrupt.Then one of two things happens:* The host never sends another message. So the pread() waits forever.* The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.This could be easily reproduced in hv_fcopy_uio_daemon if we delaysetting interrupt mask to 0.Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,there's a race condition. Once user space empties the inbound ringbuffer, but before user space sets interrupt_mask to 0, the host couldput another message in the ring buffer but it wouldn't interrupt.Then the next pread() would hang.Fix these by removing all instances where interrupt_mask is changed,while keeping the one in set_event() unchanged to enable userspacecontrol the interrupt mask by writing 0/1 to /dev/uioX.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Modify the return value checkThe return value of copy_from_iter and copy_to_iter can't be negative,check whether the copied lengths are equal.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix crypto buffers in non-linear memoryThe crypto API, through the scatterlist API, expects input buffers to bein linear memory. We handle this with the cifs_sg_set_buf() helperthat converts vmalloc'd memory to their corresponding pages.However, when we allocate our aead_request buffer (@creq insmb2ops.c::crypt_message()), we do so with kvzalloc(), which possiblyputs aead_request->__ctx in vmalloc area.AEAD algorithm then uses ->__ctx for its private/internal data andoperations, and uses sg_set_buf() for such data on a few places.This works fine as long as @creq falls into kmalloc zone (smallrequests) or vmalloc'd memory is still within linear range.Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so toomany tasks will increment the base stacks' addresses to a point wherevirt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when thathappens.In practice: too many parallel reads and writes on an encrypted mountwill trigger this bug.To fix this, always alloc @creq with kmalloc() instead.Also drop the @sensitive_size variable/arguments sincekfree_sensitive() doesn't need it.Backtrace:[ 945.272081] ------------[ cut here ]------------[ 945.272774] kernel BUG at include/linux/scatterlist.h:209![ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI[ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)[ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014[ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)[ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220[ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b[ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246[ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030[ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070[ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000[ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070[ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010[ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000[ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0[ 945.286683] Call Trace:[ 945.286952] [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs][ 945.287719] crypto_gcm_encrypt+0x36/0xe0[ 945.288152] crypt_message+0x54a/0xad0 [cifs][ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs][ 945.289300] smb_send_rqst+0xa3/0x160 [cifs][ 945.289944] cifs_call_async+0x178/0x340 [cifs][ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs][ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs][ 945.291759] ? find_held_lock+0x32/0x90[ 945.292212] ? netfs_advance_write+0xf2/0x310[ 945.292723] netfs_advance_write+0xf2/0x310[ 945.293210] netfs_write_folio+0x346/0xcc0[ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10[ 945.294250] netfs_writepages+0x117/0x460[ 945.294724] do_writepages+0xbe/0x170[ 945.295152] ? find_held_lock+0x32/0x90[ 945.295600] ? kvm_sched_clock_read+0x11/0x20[ 945.296103] __writeback_single_inode+0x56/0x4b0[ 945.296643] writeback_sb_inodes+0x229/0x550[ 945.297140] __writeback_inodes_wb+0x4c/0xe0[ 945.297642] wb_writeback+0x2f1/0x3f0[ 945.298069] wb_workfn+0x300/0x490[ 945.298472] process_one_work+0x1fe/0x590[ 945.298949] worker_thread+0x1ce/0x3c0[ 945.299397] ? __pfx_worker_thread+0x10/0x10[ 945.299900] kthr---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Disallow dirty tracking if incoherent page walkDirty page tracking relies on the IOMMU atomically updating the dirty bitin the paging-structure entry. For this operation to succeed, the paging-structure memory must be coherent between the IOMMU and the CPU. Inanother word, if the iommu page walk is incoherent, dirty page trackingdoesn't work.The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault."To prevent an IOMMU from being incorrectly configured for dirty pagetracking when it is operating in an incoherent mode, mark SSADS assupported only when both ecap_slads and ecap_smpwc are supported.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Fix incorrect handling for return value of devm_kzallocThe return value of devm_kzalloc could be an null pointer,use "!desc.pdata" to fix incorrect handling return valueof devm_kzalloc.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: Return NULL pointer for allocation failuresWhen the TRBE driver fails to allocate a buffer, it currently returnsthe error code "-ENOMEM". However, the caller etm_setup_aux() onlychecks for a NULL pointer, so it misses the error. As a result, thedriver continues and eventually causes a kernel panic.Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() onallocation failures. This allows that the callers can properly handlethe failure.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix race in do_task() when drainingWhen do_task() exhausts its iteration budget (!ret), it sets the stateto TASK_STATE_IDLE to reschedule, without a secondary check on thecurrent task->state. This can overwrite the TASK_STATE_DRAINING stateset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().While state changes are protected by a spinlock, both rxe_cleanup_task()and rxe_disable_task() release the lock while waiting for the task tofinish draining in the while(!is_done(task)) loop. The race occurs ifdo_task() hits its iteration limit and acquires the lock in this window.The cleanup logic may then proceed while the task incorrectlyreschedules itself, leading to a potential use-after-free.This bug was introduced during the migration from tasklets to workqueues,where the special handling for the draining case was lost.Fix this by restoring the original pre-migration behavior. If the state isTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 toforce a new loop iteration. This allows the task to finish its work, sothat a subsequent iteration can reach the switch statement and correctlytransition the state to TASK_STATE_DRAINED, stopping the task as intended.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regsWhen the initialization of qm->debug.acc_diff_reg fails,the probe process does not exit. However, after qm->debug.qm_diff_regs isfreed, it is not set to NULL. This can lead to a double free when theremove process attempts to free it again. Therefore, qm->debug.qm_diff_regsshould be set to NULL after it is freed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in __pnet_find_base_ndev().syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),which was called during connect(). [0]smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passesdown to pnet_find_base_ndev(), where RTNL is held. Then, UAF happenedat __pnet_find_base_ndev() when the dev is first used.This means dev had already been freed before acquiring RTNL inpnet_find_base_ndev().While dev is going away, dst->dev could be swapped with blackhole_netdev,and the dev's refcnt by dst will be released.We must hold dev's refcnt before calling smc_pnet_find_ism_resource().Also, smc_pnet_find_roce_resource() has the same problem.Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.[0]:BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f47cbf8eba9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000bRBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bacflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pps: fix warning in pps_register_cdev when register device failSimilar to previous commit 2a934fdb01db ("media: v4l2-dev: fix errorhandling in __video_register_device()"), the release hook should be setbefore device_register(). Otherwise, when device_register() return errorand put_device() try to callback the release function, the below warningmay happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),pps_register_cdev() call device_create() to create pps->dev, which willinit dev->release to device_create_release(). Now the comment is outdated,just remove it.Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removedin pps_register_source() to avoid a double free in the failure case.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don't block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when openinga DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().If basic mode is used it calls gsm_modem_upd_via_msc() and itcannot block the input queue by waiting the response to comeinto the same input queue.Instead allow sending Modem Status Command without waiting for remoteend to respond. Define a new function gsm_modem_send_initial_msc()for this purpose. As MSC is only valid for basic encoding, it doesnot do anything for advanced or when convergence layer type 2 is used.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe0e9fae16dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16dRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen hfsplus_uni2asc is called from hfsplus_listxattr,it actually passes in a struct hfsplus_attr_unistr*.The size of the corresponding structure is different from that of hfsplus_unistr,so the previous fix (94458781aee6) is insufficient.The pointer on the unicode buffer is still going beyond the allocated memory.This patch introduces two warpper functions hfsplus_uni2asc_xattr_str andhfsplus_uni2asc_str to process two unicode buffers,struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.When ustrlen value is bigger than the allocated memory size,the ustrlen value is limited to an safe size.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Define a proc_layoutcommit for the FlexFiles layout typeAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIToperation on a FlexFiles layout.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state()Return value of a function acpi_evaluate_dsm() is dereferenced withoutchecking for NULL, but it is usually checked for this function.acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returnsacpi_status other than ACPI_SUCCESS, so add a check to prevent the crach.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabledThis issue is similar to the vulnerability in the `mcp251x` driver,which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume fromsleep before interface was brought up").In the `hi311x` driver, when the device resumes from sleep, the driverschedules `priv->restart_work`. However, if the network interface wasnot previously enabled, the `priv->wq` (workqueue) is not allocated andinitialized, leading to a null pointer dereference.To fix this, we move the allocation and initialization of the workqueuefrom the `hi3110_open` function to the `hi3110_can_probe` function.This ensures that the workqueue is properly initialized before it isused during device resume. And added logic to destroy the workqueuein the error handling paths of `hi3110_can_probe` and in the`hi3110_can_remove` function to prevent resource leaks.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: rng - Ensure set_ent is always presentEnsure that set_ent is always set since only drbg provides it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()During mpt3sas_transport_port_remove(), messages were logged withdev_printk() against &mpt3sas_port->port->dev. At this point the SAStransport device may already be partially unregistered or freed, leadingto a crash when accessing its struct device.Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),guaranteed to remain valid until driver removal.[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0[83428.295844] PKRU: 55555554[83428.295846] Call Trace:[83428.295848] [83428.295850] _dev_printk+0x5c/0x80[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas][83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas][83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas][83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas][83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas][83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas][83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas][83428.295957] pci_device_remove+0x3b/0xb0[83428.295962] device_release_driver_internal+0x193/0x200[83428.295968] driver_detach+0x44/0x90[83428.295971] bus_remove_driver+0x69/0xf0[83428.295975] pci_unregister_driver+0x2a/0xb0[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas][83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296000] ? __x64_sys_getdents64+0x9a/0x110[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296009] ? syscall_trace_enter+0xf6/0x1b0[83428.296014] do_syscall_64+0x7b/0x2c0[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: max3421-hcd: Fix error pointer dereference in probe cleanupThe kthread_run() function returns error pointers so themax3421_hcd->spi_thread pointer can be either error pointers or NULL.Check for both before dereferencing it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlockPrevent USB runtime PM (autosuspend) for AX88772* in bind.usbnet enables runtime PM (autosuspend) by default, so disabling it viathe usb_driver flag is ineffective. On AX88772B, autosuspend shows nomeasurable power saving with current driver (no link partner, adminup/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib poweringthe PHY off on admin-down, not from USB autosuspend.The real hazard is that with runtime PM enabled, ndo_open() (under RTNL)may synchronously trigger autoresume (usb_autopm_get_interface()) intoasix_resume() while the USB PM lock is held. Resume paths then invokephylink/phylib and MDIO, which also expect RTNL, leading to possibledeadlocks or PM lock vs MDIO wake issues.To avoid this, keep the device runtime-PM active by taking a usagereference in ax88772_bind() and dropping it in unbind(). A non-zero PMusage count blocks runtime suspend regardless of userspace policy(.../power/control - pm_runtime_allow/forbid), making this approachrobust against sysfs overrides.Holding a runtime-PM usage ref does not affect system-wide suspend;system sleep/resume callbacks continue to run as before.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: ks-sa - fix division by zero in ks_sa_rng_initFix division by zero in ks_sa_rng_init caused by missing clockpointer initialization. The clk_get_rate() call is performed onan uninitialized clk pointer, resulting in division by zero whencalculating delay values.Add clock initialization code before using the clock. drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) whichwould lead to a error pointer dereference. Use IS_ERR_OR_NULL() to checkthat the pointer is valid.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()Currently, if find_and_map_user_pages() takes a DMA xfer request from theuser with a length field set to 0, or in a rare case, the host receivesQAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_sizeis equal to the requested transaction size, the function will return 0before allocating an sgt or setting the fields of the dma_xfer struct.In that case, encode_addr_size_pairs() will try to access the sgt whichwill lead to a general protection fault.Return an EINVAL in case the user provides a zero-sized ALP, or the devicerequests continuation after all of the bytes have been transferred.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: berlin: Fix wrong register in suspend/resumeThe 'enable' register should be BERLIN_PWM_EN rather thanBERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, therewill be cpu exception then kernel panic during suspend/resume.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()Unlike other strings in the ext4 superblock, we rely on tune2fs tomake sure s_mount_opts is NUL terminated. Hardenparse_apply_sb_mount_options() by treating s_mount_opts as a potential__nonstring.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: reject negative file sizes in squashfs_read_inode()Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size.This commit checks for a negative file size and returns EINVAL.[phillip@squashfs.org.uk: only need to check 64 bit quantity]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid potential out-of-bounds in btrfs_encode_fh()The function btrfs_encode_fh() does not properly account for the threecases it handles.Before writing to the file handle (fh), the function only returns to theuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) orBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).However, when a parent exists and the root ID of the parent and theinode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT(10 dwords, 40 bytes).If *max_len is not large enough, this write goes out of bounds becauseBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater thanBTRFS_FID_SIZE_CONNECTABLE originally returned.This results in an 8-byte out-of-bounds write atfid->parent_root_objectid = parent_root_id.A previous attempt to fix this issue was made but was lost.https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/Although this issue does not seem to be easily triggerable, it is apotential memory corruption bug that should be fixed. This patchresolves the issue by ensuring the function returns the appropriate sizefor all three cases and validates that *max_len is large enough beforewriting any data.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()v4l2_subdev_call_state_try() macro allocates a subdev state with__v4l2_subdev_state_alloc(), but does not check the returned value. If__v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that wouldcause v4l2_subdev_call_state_try() to crash.Add proper error handling to v4l2_subdev_call_state_try().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- libsqlite3-0 > 0-0 (version in image is 3.50.2-150000.3.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: fix shift-out-of-bounds in exponential backoffThe ENA adapters on our instances occasionally reset. Once recentlylogged a UBSAN failure to console in the process: UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue: ena ena_fw_reset_device [ena] Call Trace: dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e ? __const_udelay+0x43/0x50 ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena] wait_for_reset_state+0x54/0xa0 [ena] ena_com_dev_reset+0xc8/0x110 [ena] ena_down+0x3fe/0x480 [ena] ena_destroy_device+0xeb/0xf0 [ena] ena_fw_reset_device+0x30/0x50 [ena] process_one_work+0x22b/0x3d0 worker_thread+0x4d/0x3f0 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Apparently, the reset delays are getting so large they can trigger aUBSAN panic.Looking at the code, the current timeout is capped at 5000us. Using abase value of 100us, the current code will overflow after (1<<29). Evenat values before 32, this function wraps around, perhapsunintentionally.Cap the value of the exponent used for this backoff at (1<<16) which islarger than currently necessary, but large enough to support biggervalues in the future.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix possible data races in gfs2_show_options()Some fields such as gt_logd_secs of the struct gfs2_tune are accessedwithout holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);And thus can cause data races when gfs2_show_options() and other functionssuch as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit;To fix these possible data races, the lock sdp->sd_tune.gt_spin isacquired before accessing the fields of gfs2_tune and released after theseaccesses.Further changes by Andreas:- Don't hold the spin lock over the seq_printf operations.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: amd_sfh: Fix for shift-out-of-boundsShift operation of 'exp' and 'shift' variables exceeds the maximum numberof shift values in the u32 range leading to UBSAN shift-out-of-bounds....[ 6.120512] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50[ 6.120598] shift exponent 104 is too large for 64-bit type 'long unsigned int'[ 6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10[ 6.120665] Hardware name: AMD Birman-PHX/Birman-PHX, BIOS SFH_with_HPD_SEN.FD 04/05/2023[ 6.120667] Workqueue: events amd_sfh_work_buffer [amd_sfh][ 6.120687] Call Trace:[ 6.120690] [ 6.120694] dump_stack_lvl+0x48/0x70[ 6.120704] dump_stack+0x10/0x20[ 6.120707] ubsan_epilogue+0x9/0x40[ 6.120716] __ubsan_handle_shift_out_of_bounds+0x10f/0x170[ 6.120720] ? psi_group_change+0x25f/0x4b0[ 6.120729] float_to_int.cold+0x18/0xba [amd_sfh][ 6.120739] get_input_rep+0x57/0x340 [amd_sfh][ 6.120748] ? __schedule+0xba7/0x1b60[ 6.120756] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh][ 6.120764] amd_sfh_work_buffer+0x91/0x180 [amd_sfh][ 6.120772] process_one_work+0x229/0x430[ 6.120780] worker_thread+0x4a/0x3c0[ 6.120784] ? __pfx_worker_thread+0x10/0x10[ 6.120788] kthread+0xf7/0x130[ 6.120792] ? __pfx_kthread+0x10/0x10[ 6.120795] ret_from_fork+0x29/0x50[ 6.120804] ...Fix this by adding the condition to validate shift ranges.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a potential data corruptionWe must ensure that the subrequests are joined back into the head beforewe can retransmit a request. If the head was not on the commit lists,because the server wrote it synchronously, we still need to add it backto the retransmission list.Add a call that mirrors the effect of nfs_cancel_remove_inode() forO_DIRECT.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Do not swap cpu_buffer during resize processWhen ring_buffer_swap_cpu was called during resize process,the cpu buffer was swapped in the middle, resulting in incorrect state.Continuing to run in the wrong state will result in oops.This issue can be easily reproduced using the following two scripts:/tmp # cat test1.sh//#! /bin/shfor i in `seq 0 100000`do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo 5000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5done/tmp # cat test2.sh//#! /bin/shfor i in `seq 0 100000`do echo irqsoff > /sys/kernel/debug/tracing/current_tracer sleep 1 echo nop > /sys/kernel/debug/tracing/current_tracer sleep 1done/tmp # ./test1.sh &/tmp # ./test2.sh &A typical oops log is as follows, sometimes with other different oops logs.[ 231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8[ 231.713375] Modules linked in:[ 231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15[ 231.716750] Hardware name: linux,dummy-virt (DT)[ 231.718152] Workqueue: events update_pages_handler[ 231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 231.721171] pc : rb_update_pages+0x378/0x3f8[ 231.722212] lr : rb_update_pages+0x25c/0x3f8[ 231.723248] sp : ffff800082b9bd50[ 231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000[ 231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0[ 231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a[ 231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000[ 231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510[ 231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002[ 231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558[ 231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001[ 231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000[ 231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208[ 231.744196] Call trace:[ 231.744892] rb_update_pages+0x378/0x3f8[ 231.745893] update_pages_handler+0x1c/0x38[ 231.746893] process_one_work+0x1f0/0x468[ 231.747852] worker_thread+0x54/0x410[ 231.748737] kthread+0x124/0x138[ 231.749549] ret_from_fork+0x10/0x20[ 231.750434] ---[ end trace 0000000000000000 ]---[ 233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 233.721696] Mem abort info:[ 233.721935] ESR = 0x0000000096000004[ 233.722283] EC = 0x25: DABT (current EL), IL = 32 bits[ 233.722596] SET = 0, FnV = 0[ 233.722805] EA = 0, S1PTW = 0[ 233.723026] FSC = 0x04: level 0 translation fault[ 233.723458] Data abort info:[ 233.723734] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 233.724176] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 233.724589] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000[ 233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[ 233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 233.726720] Modules linked in:[ 233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15[ 233.727777] Hardware name: linux,dummy-virt (DT)[ 233.728225] Workqueue: events update_pages_handler[ 233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 233.729054] pc : rb_update_pages+0x1a8/0x3f8[ 233.729334] lr : rb_update_pages+0x154/0x3f8[ 233.729592] sp : ffff800082b9bd50[ 233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 00000000---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that's racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- curl > 0-0 (version in image is 8.14.1-150600.4.28.1).
-
Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- curl > 0-0 (version in image is 8.14.1-150600.4.28.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- curl > 0-0 (version in image is 8.14.1-150600.4.28.1).
-
Description: The attack vector is a potential Denial of Service (DoS). The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libruby2_5-2_5 < 2.5.9-150000.4.54.1 (version in image is 2.5.9-150000.4.49.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in cifs_oplock_breakA race condition can occur in cifs_oplock_break() leading to ause-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAFThe issue occurs when umount has already released its reference to thesuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), thisreleases the last reference, triggering the immediate cleanup of allinodes under RCU. However, cifs_oplock_break() continues to access thecinode after this point, resulting in use-after-free.Fix this by holding an extra reference to the superblock during theentire oplock break operation. This ensures that the superblock andits inodes remain valid until the oplock break completes.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz bandWith a quite rare chance, RX report might be problematic to make SW thinka packet is received on 6 GHz band even if the chip does not support 6 GHzband actually. Since SW won't initialize stuffs for unsupported bands, NULLdereference will happen then in the sequence, rtw89_vif_rx_stats_iter() ->rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it.The following is a crash log for this case. BUG: kernel NULL pointer dereference, address: 0000000000000032 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)] rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: shutdown driver when hardware is unreliableIn rare cases, ath10k may lose connection with the PCIe bus due tosome unknown reasons, which could further lead to system crashes duringresuming due to watchdog timeout:ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardwareath10k_pci 0000:01:00.0: already restartingath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11ieee80211 phy0: PM: **** DPM device timeout ****Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13cAt this point, all WMI commands will timeout and attempt to restartdevice. So set a threshold for consecutive restart failures. If thethreshold is exceeded, consider the hardware is unreliable and allath10k operations should be skipped to avoid system crash.fail_cont_count and pending_recovery are atomic variables, anddo not involve complex conditional logic. Therefore, even if recoverycheck and reconfig complete are executed concurrently, the recoverymechanism will not be broken.Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPEOn Google gs101, the number of UTP transfer request slots (nutrs) is 32,and in this case the driver ends up programming the UTRL_NEXUS_TYPEincorrectly as 0.This is because the left hand side of the shift is 1, which is of typeint, i.e. 31 bits wide. Shifting by more than that width results inundefined behaviour.Fix this by switching to the BIT() macro, which applies correct typecasting as required. This ensures the correct value is written toUTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shiftwarning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int'For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPEwrite.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: initialize more fields in sctp_v6_from_sk()syzbot found that sin6_scope_id was not properly initialized,leading to undefined behavior.Clear sin6_scope_id and sin6_flowinfo.BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()The hfsplus_strcasecmp() logic can trigger the issue:[ 117.317703][ T9855] ==================================================================[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855[ 117.319577][ T9855][ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 117.319783][ T9855] Call Trace:[ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319842][ T9855] print_report+0x17e/0x7e0[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319876][ T9855] kasan_report+0x147/0x180[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0[ 117.320055][ T9855] lookup_slow+0x53/0x70[ 117.320065][ T9855] walk_component+0x2f0/0x430[ 117.320073][ T9855] path_lookupat+0x169/0x440[ 117.320081][ T9855] filename_lookup+0x212/0x590[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540[ 117.320112][ T9855] user_path_at+0x3a/0x60[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: move lsop put work to nvmet_fc_ls_req_opIt's possible for more than one async command to be in flight from__nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.In the current code, only one put work item is queued at a time, whichresults in a leaked reference.To fix this, move the work item to the nvmet_fc_ls_req_op struct, whichalready tracks all resources related to the command.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}Cilium has a BPF egress gateway feature which forces outgoing K8s Podtraffic to pass through dedicated egress gateways which then SNAT thetraffic in order to interact with stable IPs outside the cluster.The traffic is directed to the gateway via vxlan tunnel in collect mdmode. A recent BPF change utilized the bpf_redirect_neigh() helper toforward packets after the arrival and decap on vxlan, which turned outover time that the kmalloc-256 slab usage in kernel was ever-increasing.The issue was that vxlan allocates the metadata_dst object and attachesit through a fake dst entry to the skb. The latter was never releasedthough given bpf_redirect_neigh() was merely setting the new dst entryvia skb_dst_set() without dropping an existing one first.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
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-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
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-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- openssh < 9.6p1-150600.6.34.1 (version in image is 9.6p1-150600.6.29.2).
-
Description: ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- openssh < 9.6p1-150600.6.34.1 (version in image is 9.6p1-150600.6.29.2).
-
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.6 (version in image is 15.6-150600.37.2).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
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.6 (version in image is 15.6-150600.37.2).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
Description: Marshmallow is a lightweight library for converting complex objects to and from simple Python datatypes. In versions from 3.0.0rc1 to before 3.26.2 and from 4.0.0 to before 4.1.2, Schema.load(data, many=True) is vulnerable to denial of service attacks. A moderately sized request can consume a disproportionate amount of CPU time. This issue has been patched in version 3.26.2 and 4.1.2.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- python311-marshmallow > 0-0 (version in image is 3.20.2-150400.9.7.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below contain parser logic which allows non-ASCII decimals to be present in the Range header. There is no known impact, but there is the possibility that there's a method to exploit a request smuggling vulnerability. This issue is fixed in version 3.13.3.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below enable an attacker to ascertain the existence of absolute path components through the path normalization logic for static files meant to prevent path traversal. If an application uses web.static() (not recommended for production deployments), it may be possible for an attacker to ascertain the existence of path components. This issue is fixed in version 3.13.3.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
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.6 (version in image is 15.6-150600.37.2).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: Skip DIMM enumeration on a disabled memory controllerWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ...This occurs because some BIOS may disable a memory controller if therearen't any memory DIMMs populated on this memory controller. The DIMMMTRregister of this disabled memory controller contains the invalid value~0, resulting in the call trace above.Fix this call trace by skipping DIMM enumeration on a disabled memorycontroller.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: core: config: Prevent OOB read in SS endpoint companion parsingusb_parse_ss_endpoint_companion() checks descriptor type before length,enabling a potentially odd read outside of the buffer size.Fix this up by checking the size first before looking at any of thefields in the descriptor.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_objref: validate objref and objrefmap expressionsReferencing a synproxy stateful object from OUTPUT hook causes kernelcrash due to infinite recursive calls:BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12)[...]Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0[...]Implement objref and objrefmap expression validate functions.Currently, only NFT_OBJECT_SYNPROXY object type requires validation.This will also handle a jump to a chain using a synproxy object from theOUTPUT hook.Now when trying to reference a synproxy object in the OUTPUT hook, nftwill produce the following error:synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- containerd < 1.7.29-150000.128.1 (version in image is 1.7.27-150000.123.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: make fallback action and fallback decision atomicSyzkaller reported the following splat: WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- grub2 < 2.12-150600.8.44.2 (version in image is 2.12-150600.8.37.1).
-
Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- grub2 < 2.12-150600.8.44.2 (version in image is 2.12-150600.8.37.1).
-
Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- grub2 < 2.12-150600.8.44.2 (version in image is 2.12-150600.8.37.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- grub2 < 2.12-150600.8.44.2 (version in image is 2.12-150600.8.37.1).
-
Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- grub2 < 2.12-150600.8.44.2 (version in image is 2.12-150600.8.37.1).
-
Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- glib2-tools < 2.78.6-150600.4.22.1 (version in image is 2.78.6-150600.4.16.1).
-
Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- grub2 < 2.12-150600.8.44.2 (version in image is 2.12-150600.8.37.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: fix null pointer dereference in ovl_permission()Following process: P1 P2 path_lookupat link_path_walk inode_permission ovl_permission ovl_i_path_real(inode, &realpath) path->dentry = ovl_i_dentry_upper(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 realinode = d_inode(realpath.dentry) // return NULL inode_permission(realinode) inode->i_sb // NULL pointer dereference, will trigger an null pointer dereference at realinode: [ 335.664979] BUG: kernel NULL pointer dereference, address: 0000000000000002 [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0 [ 335.669956] RIP: 0010:inode_permission+0x33/0x2c0 [ 335.678939] Call Trace: [ 335.679165] [ 335.679371] ovl_permission+0xde/0x320 [ 335.679723] inode_permission+0x15e/0x2c0 [ 335.680090] link_path_walk+0x115/0x550 [ 335.680771] path_lookupat.isra.0+0xb2/0x200 [ 335.681170] filename_lookup+0xda/0x240 [ 335.681922] vfs_statx+0xa6/0x1f0 [ 335.682233] 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.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_noneAfter grabbing q->sysfs_lock, q->elevator may become NULL because ofelevator switch.Fix the NULL dereference on q->elevator by checking it with lock.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix unsafe drain work queue codeIf create_qp does not fully succeed it is possible for qp cleanupcode to attempt to drain the send or recv work queues before thequeues have been created causing a seg fault. This patch checksto see if the queues exist before attempting to drain them.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix poll request timeout handlingWhen doing io_uring benchmark on /dev/nullb0, it's easy to crash thekernel if poll requests timeout triggered, as reported by David. [1]BUG: kernel NULL pointer dereference, address: 0000000000000008Workqueue: kblockd blk_mq_timeout_workRIP: 0010:null_timeout_rq+0x4e/0x91Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227This is indeed a race problem between null_timeout_rq() and null_poll().null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock)Fix these problems by setting requests state to MQ_RQ_COMPLETE undernq->poll_lock protection, in which null_timeout_rq() can safely detectthis race and early return.Note this patch just fix the kernel panic when request timeout happen.[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: insert tree mod log move in push_node_leftThere is a fairly unlikely race condition in tree mod log rewind thatcan result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0This occurs when logical inode resolution takes a tree mod log sequencenumber, and then while backref walking hits a rewind on a busy nodewhich has the following sequence of tree mod log operations (numbersfilled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0When this sequence gets applied via btrfs_tree_mod_log_rewind, itallocates a fresh rewind eb, and first inserts the correct key info forthe 533 elements, then overwrites the first 456 of them, then decrementsthe count by 456 via the add ops, then rewinds the move by doing amemmove from 456:988->0:532. We have never written anything past 532,---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Check for NOT_READY flag state after lockingCurrently the check for NOT_READY flag is performed before obtaining thenecessary lock. This opens a possibility for race condition when the flowis concurrently removed from unready_flows list by the workqueue task,which causes a double-removal from the list and a crash[0]. Fix the issueby moving the flag check inside the section protected byuplink_priv->unready_flows_lock mutex.[0]:[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core][44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000[44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000[44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[44376.406339] Call Trace:[44376.406651] [44376.406939] ? die_addr+0x33/0x90[44376.407311] ? exc_general_protection+0x192/0x390[44376.407795] ? asm_exc_general_protection+0x22/0x30[44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core][44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core][44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core][44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core][44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core][44376.411043] tc_setup_cb_reoffload+0x22/0x80[44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower][44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core][44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core][44376.413044] tcf_block_playback_offloads+0x76/0x170[44376.413497] tcf_block_unbind+0x7b/0xd0[44376.413881] tcf_block_setup+0x17d/0x1c0[44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130[44376.414725] tcf_block_offload_unbind+0x43/0x70[44376.415153] __tcf_block_put+0x82/0x150[44376.415532] ingress_destroy+0x22/0x30 [sch_ingress][44376.415986] qdisc_destroy+0x3b/0xd0[44376.416343] qdisc_graft+0x4d0/0x620[44376.416706] tc_get_qdisc+0x1c9/0x3b0[44376.417074] rtnetlink_rcv_msg+0x29c/0x390[44376.419978] ? rep_movs_alternative+0x3a/0xa0[44376.420399] ? rtnl_calcit.isra.0+0x120/0x120[44376.420813] netlink_rcv_skb+0x54/0x100[44376.421192] netlink_unicast+0x1f6/0x2c0[44376.421573] netlink_sendmsg+0x232/0x4a0[44376.421980] sock_sendmsg+0x38/0x60[44376.422328] ____sys_sendmsg+0x1d0/0x1e0[44376.422709] ? copy_msghdr_from_user+0x6d/0xa0[44376.423127] ___sys_sendmsg+0x80/0xc0[44376.423495] ? ___sys_recvmsg+0x8b/0xc0[44376.423869] __sys_sendmsg+0x51/0x90[44376.424226] do_syscall_64+0x3d/0x90[44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0[44376.425046] RIP: 0033:0x7f045134f887[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix memory leak in WMI firmware statsMemory allocated for firmware pdev, vdev and beacon statisticsare not released during rmmod.Fix it by calling ath11k_fw_stats_free() function before hardwareunregister.While at it, avoid calling ath11k_fw_stats_free() while processingthe firmware stats received in the WMI event because the local listis getting spliced and reinitialised and hence there are no elementsin the list after splicing.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}If the filename casefolding fails, we'll be leaking memory from thefscrypt_name struct, namely from the 'crypto_buf.name' member.Make sure we free it in the error path on both ext4_fname_setup_filename()and ext4_fname_prepare_lookup() functions.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_costadjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabledwhen unlock. DEADLOCK might happen if we have held other locks and disabledIRQ before invoking it.Fix it by using spin_lock_irqsave() instead, which can keep IRQ stateconsistent with before when unlock. ================================ WARNING: inconsistent lock state 5.10.0-02758-g8e5f91fd772f #26 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 {IN-HARDIRQ-W} state was registered at: __lock_acquire+0x3d7/0x1070 lock_acquire+0x197/0x4a0 __raw_spin_lock_irqsave _raw_spin_lock_irqsave+0x3b/0x60 bfq_idle_slice_timer_body bfq_idle_slice_timer+0x53/0x1d0 __run_hrtimer+0x477/0xa70 __hrtimer_run_queues+0x1c6/0x2d0 hrtimer_interrupt+0x302/0x9e0 local_apic_timer_interrupt __sysvec_apic_timer_interrupt+0xfd/0x420 run_sysvec_on_irqstack_cond sysvec_apic_timer_interrupt+0x46/0xa0 asm_sysvec_apic_timer_interrupt+0x12/0x20 irq event stamp: 837522 hardirqs last enabled at (837521): [] __raw_spin_unlock_irqrestore hardirqs last enabled at (837521): [] _raw_spin_unlock_irqrestore+0x3d/0x40 hardirqs last disabled at (837522): [] __raw_spin_lock_irq hardirqs last disabled at (837522): [] _raw_spin_lock_irq+0x43/0x50 softirqs last enabled at (835852): [] __do_softirq+0x558/0x8ec softirqs last disabled at (835845): [] asm_call_irq_on_stack+0xf/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&bfqd->lock); lock(&bfqd->lock); *** DEADLOCK *** 3 locks held by kworker/2:3/388: #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0 #1: ffff8881176bfdd8 ((work_completion)(&td->dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0 #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 stack backtrace: CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kthrotld blk_throtl_dispatch_work_fn Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x167 print_usage_bug valid_state mark_lock_irq.cold+0x32/0x3a mark_lock+0x693/0xbc0 mark_held_locks+0x9e/0xe0 __trace_hardirqs_on_caller lockdep_hardirqs_on_prepare.part.0+0x151/0x360 trace_hardirqs_on+0x5b/0x180 __raw_spin_unlock_irq _raw_spin_unlock_irq+0x24/0x40 spin_unlock_irq adjust_inuse_and_calc_cost+0x4fb/0x970 ioc_rqos_merge+0x277/0x740 __rq_qos_merge+0x62/0xb0 rq_qos_merge bio_attempt_back_merge+0x12c/0x4a0 blk_mq_sched_try_merge+0x1b6/0x4d0 bfq_bio_merge+0x24a/0x390 __blk_mq_sched_bio_merge+0xa6/0x460 blk_mq_sched_bio_merge blk_mq_submit_bio+0x2e7/0x1ee0 __submit_bio_noacct_mq+0x175/0x3b0 submit_bio_noacct+0x1fb/0x270 blk_throtl_dispatch_work_fn+0x1ef/0x2b0 process_one_work+0x83e/0x13f0 process_scheduled_works worker_thread+0x7e3/0xd80 kthread+0x353/0x470 ret_from_fork+0x1f/0x30
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: fix potential deadlock in netlink_set_err()syzbot reported a possible deadlock in netlink_set_err() [1]A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQsfor netlink_lock_table()") in netlink_lock_table()This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()which were not covered by cited commit.[1]WARNING: possible irq lock inversion dependency detected6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not taintedsyz-executor.2/23011 just changed the state of lock:ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2}and interrupts could create inverse lock ordering between them.other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); lock(&local->queue_stop_reason_lock); *** DEADLOCK ***
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring ESTIf the ptp_rate recorded earlier in the driver happens to be 0, thisbogus value will propagate up to EST configuration, where it willtrigger a division by 0.Prevent this division by 0 by adding the corresponding check and errorcode.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/rt: Fix race in push_rt_taskOverview========When a CPU chooses to call push_rt_task and picks a task to push toanother CPU's runqueue then it will call find_lock_lowest_rq methodwhich would take a double lock on both CPUs' runqueues. If one of thelocks aren't readily available, it may lead to dropping the currentrunqueue lock and reacquiring both the locks at once. During this windowit is possible that the task is already migrated and is running on someother CPU. These cases are already handled. However, if the task ismigrated and has already been executed and another CPU is now trying towake it up (ttwu) such that it is queued again on the runqeue(on_rq is 1) and also if the task was run by the same CPU, then thecurrent checks will pass even though the task was migrated out and is nolonger in the pushable tasks list.Crashes=======This bug resulted in quite a few flavors of crashes triggering kernelpanics with various crash signatures such as assert failures, pagefaults, null pointer dereferences, and queue corruption errors allcoming from scheduler itself.Some of the crashes:-> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb-> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb-> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p))-> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7-> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_i---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().syzbot reported a warning below during atm_dev_register(). [0]Before creating a new device and procfs/sysfs for it, atm_dev_register()looks up a duplicated device by __atm_dev_lookup(). These operations aredone under atm_dev_mutex.However, when removing a device in atm_dev_deregister(), it releases themutex just after removing the device from the list that __atm_dev_lookup()iterates over.So, there will be a small race window where the device does not exist onthe device list but procfs/sysfs are still not removed, triggering thesplat.Let's hold the mutex until procfs/sysfs are removed inatm_dev_deregister().[0]:proc_dir_entry 'atm/atmtcp:0' already registeredWARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377Modules linked in:CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f38b3b74459Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0acR13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack: fix crash due to removal of uninitialised entryA crash in conntrack was reported while trying to unlink the conntrackentry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..]The nf_conn struct is marked as allocated from slab but appears to be ina partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected.Everything else looks like normal udp conntrack entry. If we ignorect->status and pretend its 0, the entry matches those that are newlyallocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value.If it were not for the presence of IPS_CONFIRMED,__nf_conntrack_find_get() would have skipped the entry.Theory is that we did hit following race:cpu x cpu y cpu z found entry E found entry E E is expired
nf_ct_delete() return E to rcu slab init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value.cpu y found E right before it was deleted on cpu x.E is now re-inited on cpu z. cpu y was preempted beforechecking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb ->timeout set to 30000If cpu y were to resume now, it would observe E asexpired but would skip E due to missing CONFIRMED bit. nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable.cpu y resumes, it observes E as expired but CONFIRMED: nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set.cpu y will try to delete E from the hashtable: nf_ct_delete() -> set DYING bit __nf_ct_delete_from_listsEven this scenario doesn't guarantee a crash:cpu z still holds the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is set but there is no guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP In case CPU z does insert the entry into the hashtable, cpu y will unlinkE again right away but no crash occurs.Without 'cpu y' race, 'garbage' hlist is of no consequence:ct refcnt remains at 1, eventually skb will be free'd and E getsdestroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy.To resolve this, move the IPS_CONFIRMED assignment after the tableinsertion but before the unlock.Pablo points out that the confirm-bit-store could be reordered to happenbefore hlist add resp. the timeout fixup, so switch to set_bit andbefore_atomic memory barrier to prevent this.It doesn't matter if other CPUs can observe a newly inserted entry rightbefore the CONFIRMED bit was set:Such event cannot be distinguished from above "E is the old incarnation"case: the entry will be skipped.Also change nf_ct_should_gc() to first check the confirmed bit.The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nf_ct_should_gc() to double-check step 1.nf_ct_should_gc() is thus called only for entries that already failed anexpiry check. After this patch, once the confirmed bit check pas---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). Forexample, the following is possible: T0 T1zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i
type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULLSince there is a small gap between checking skb queue length and skb beingunconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.In order to avoid potential NULL pointer dereference due to situations likeabove, check if skb is not NULL before passing it to zd_mac_tx_status().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Increment job count before swapping tail spsc queueA small race exists between spsc_queue_push and the run-job worker, inwhich spsc_queue_push may return not-first while the run-job worker hasalready idled due to the job count being zero. If this race occurs, jobscheduling stops, leading to hangs while waiting on the job's DMAfences.Seal this race by incrementing the job count before appending to theSPSC queue.This race was observed on a drm-tip 6.16-rc1 build with the Xe driver inan SVM test case.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Don't call mmput from MMU notifier callbackIf the process is exiting, the mmput inside mmu notifier callback fromcompactd or fork or numa balancing could release the last referenceof mm struct to call exit_mmap and free_pgtable, this triggers deadlockwith below backtrace.The deadlock will leak kfd process as mmu notifier release is not calledand cause VRAM leaking.The fix is to take mm reference mmget_non_zero when adding prange to thedeferred list to pair with mmput in deferred list work.If prange split and add into pchild list, the pchild work_item.mm is notused, so remove the mm parameter from svm_range_unmap_split andsvm_range_add_child.The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu](cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: nbpfaxi: Fix memory corruption in probe()The nbpf->chan[] array is allocated earlier in the nbpf_probe() functionand it has "num_channels" elements. These three loops iterate oneelement farther than they should and corrupt memory.The changes to the second loop are more involved. In this case, we'recopying data from the irqbuf[] array into the nbpf->chan[] array. Ifthe data in irqbuf[i] is the error IRQ then we skip it, so the iteratorsare not in sync. I added a check to ensure that we don't go beyond theend of the irqbuf[] array. I'm pretty sure this can't happen, but itseemed harmless to add a check.On the other hand, after the loop has ended there is a check to ensurethat the "chan" iterator is where we expect it to be. In the originalcode we went one element beyond the end of the array so the iteratorwasn't in the correct place and it would always return -EINVAL. However,now it will always be in the correct place. I deleted the check sincewe know the result.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix bug due to prealloc collisionWhen userspace is using AF_RXRPC to provide a server, it has to preallocateincoming calls and assign to them call IDs that will be used to threadrelated recvmsg() and sendmsg() together. The preallocated call IDs willautomatically be attached to calls as they come in until the pool is empty.To the kernel, the call IDs are just arbitrary numbers, but userspace canuse the call ID to hold a pointer to prepared structs. In any case, theuser isn't permitted to create two calls with the same call ID (call IDsbecome available again when the call ends) and EBADSLT should result fromsendmsg() if an attempt is made to preallocate a call with an in-use callID.However, the cleanup in the error handling will trigger both assertions inrxrpc_cleanup_call() because the call isn't marked complete and isn'tmarked as having been released.Fix this by setting the call state in rxrpc_service_prealloc_one() and thenmarking it as being released before calling the cleanup function.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix memory leak of struct clip_vcc.ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it tovcc->user_back.The code assumes that vcc_destroy_socket() passes NULL skbto vcc->push() when the socket is close()d, and then clip_push()frees clip_vcc.However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() inatm_init_atmarp(), resulting in memory leak.Let's serialise two ioctl() by lock_sock() and check vcc->push()in atm_init_atmarp() to prevent memleak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: Make EEH driver device hotplug safeMultiple race conditions existed between the PCIe hotplug driver and theEEH driver, leading to a variety of kernel oopses of the same generalnature:
A second class of oops is also seen when the underlying bus disappearsduring device recovery.Refactor the EEH module to be PCI rescan and remove safe. Also cleanup a few minor formatting / readability issues.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'Function 'hci_discovery_filter_clear()' frees 'uuids' array and thensets it to NULL. There is a tiny chance of the following race:'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL;To fix it let's add locking around 'kfree()' call and NULL pointerassignment. Otherwise the following backtrace fires:[ ] ------------[ cut here ]------------[ ] kernel BUG at mm/slub.c:547![ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1[ ] Tainted: [O]=OOT_MODULE[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ ] pc : __slab_free+0xf8/0x348[ ] lr : __slab_free+0x48/0x348...[ ] Call trace:[ ] __slab_free+0xf8/0x348[ ] kfree+0x164/0x27c[ ] start_service_discovery+0x1d0/0x2c0[ ] hci_sock_sendmsg+0x518/0x924[ ] __sock_sendmsg+0x54/0x60[ ] sock_write_iter+0x98/0xf8[ ] do_iter_readv_writev+0xe4/0x1c8[ ] vfs_writev+0x128/0x2b0[ ] do_writev+0xfc/0x118[ ] __arm64_sys_writev+0x20/0x2c[ ] invoke_syscall+0x68/0xf0[ ] el0_svc_common.constprop.0+0x40/0xe0[ ] do_el0_svc+0x1c/0x28[ ] el0_svc+0x30/0xd0[ ] el0t_64_sync_handler+0x100/0x12c[ ] el0t_64_sync+0x194/0x198[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)[ ] ---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: fix UAF in dmabuf_exp_from_pages()[dma_buf_fd() fixes; no preferences regarding the tree it goes through -up to xen folks]As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().gntdev dmabuf_exp_from_pages() calls it and then proceeds to access theobjects destroyed on close - starting with gntdev_dmabuf itself.Fix that by doing reserving descriptor before anything else and dofd_install() only when everything had been set up.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: fix race causing mux_owner NULL with active mux_usecountcommit 5a3e85c3c397 ("pinmux: Use sequential access to accessdesc->pinmux data") tried to address the issue when two client of thesame gpio calls pinctrl_select_state() for the same functionality, wasresulting in NULL pointer issue while accessing desc->mux_owner.However, issue was not completely fixed due to the way it was handledand it can still result in the same NULL pointer.The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux)This sequence leads to a state where the pin appears to be in use(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which cancause NULL pointer on next pin_request on the same pin.Ensure that updates to mux_usecount and mux_owner are performedatomically under the same lock. Only clear mux_owner when mux_usecountreaches zero and no new owner has been assigned.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: remove mutex_lock check in hfsplus_free_extentsSyzbot reported an issue in hfsplus filesystem:------------[ cut here ]------------WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0Call Trace:hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56cont_expand_zero fs/buffer.c:2383 [inline]cont_write_begin+0x2cf/0x860 fs/buffer.c:2446hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263notify_change+0xe38/0x10f0 fs/attr.c:420do_truncate+0x1fb/0x2e0 fs/open.c:65do_sys_ftruncate+0x2eb/0x380 fs/open.c:193do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdTo avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlockon file truncation") unlock extree before hfsplus_free_extents(),and add check wheather extree is locked in hfsplus_free_extents().However, when operations such as hfsplus_file_release,hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executedconcurrently in different files, it is very likely to trigger theWARN_ON, which will lead syzbot and xfstest to consider it as anabnormality.The comment above this warning also describes one of the easytriggering situations, which can easily trigger and causexfstest&syzbot to report errors.[task A] [task B]->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!Several threads could try to lock the shared extents tree.And warning can be triggered in one thread when another threadhas locked the tree. This is the wrong behavior of the code andwe need to remove the warning.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Avoid stack buffer overflow from kernel cmdlineWhile the kernel command line is considered trusted in most environments,avoid writing 1 byte past the end of "acpiid" if the "str" argument ismaximum length.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structureIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, theresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() mayoccur before sli4_hba.hdwqs are allocated. This may result in a nullpointer dereference when attempting to take the abts_io_buf_list_lock forthe first hardware queue. Fix by adding a null ptr check onphba->sli4_hba.hdwq and early return because this situation means theremust have been an error during port initialization.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: do not BUG when INLINE_DATA_FL lacks system.data xattrA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()when an inode had the INLINE_DATA_FL flag set but was missing thesystem.data extended attribute.Since this can happen due to a maiciouly fuzzed file system, weshouldn't BUG, but rather, report it as a corrupted file system.Add similar replacements of BUG_ON with EXT4_ERROR_INODE() iiext4_create_inline_data() and ext4_inline_data_truncate().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()snd_soc_remove_pcm_runtime() might be called with rtd == NULL which willleads to null pointer dereference.This was reproduced with topology loading and marking a link as ignoredue to missing hardware component on the system.On module removal the soc_tplg_remove_link() would callsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,no runtime was created.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Check encryption key size on incoming connectionThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bitThis tests the security key with size from 1 to 15 bytes while theSecurity Mode 4 Level 4 requests 16 bytes key size.Currently PTS fails with the following logs:- expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt),but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information availableAnd HCI logs:< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)> HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7> ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64< ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Initialize the chan_stats array to zeroThe adapter->chan_stats[] array is initialized inmwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero outmemory. The array is filled in mwifiex_update_chan_statistics()and then the user can query the data in mwifiex_cfg80211_dump_survey().There are two potential issues here. What if the user callsmwifiex_cfg80211_dump_survey() before the data has been filled in.Also the mwifiex_update_chan_statistics() function doesn't necessarilyinitialize the whole array. Since the array was not initialized atthe start that could result in an information leak.Also this array is pretty small. It's a maximum of 900 bytes so it'smore appropriate to use kcalloc() instead vmalloc().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix Use-after-free in validationNodes stored in the validation duplicates hashtable come from an arenaallocator that is cleared at the end of vmw_execbuf_process. All nodesare expected to be cleared in vmw_validation_drop_ht but this node escapedbecause its resource was destroyed prematurely.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix using smp_processor_id() in preemptible code warningsSyzbot reported the following warning:BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFor historical and portability reasons, the netif_rx() is usuallyrun in the softirq or interrupt context, this commit therefore addlocal_bh_disable/enable() protection in the usbnet_resume_rx().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()The cpufreq_cpu_put() call in update_qos_request() takes place too earlybecause the latter subsequently calls freq_qos_update_request() thatindirectly accesses the policy object in question through the QoS requestobject passed to it.Fortunately, update_qos_request() is called under intel_pstate_driver_lock,so this issue does not matter for changing the intel_pstate operationmode, but it theoretically can cause a crash to occur on CPU device hotremoval (which currently can only happen in virt, but it is formallysupported nevertheless).Address this issue by modifying update_qos_request() to drop thereference to the policy later.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-mem2mem: add lock to protect parameter num_rdyGetting below error when using KCSAN to check the driver. Adding lock toprotect parameter num_rdy when getting the value with function:v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queuekworker/u16:3: [name:report&]kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-containers-release == 15.6 (version in image is 15.6-150600.37.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: A vulnerability was found in GNU Binutils 2.43 and classified as critical. This issue affects the function _bfd_elf_gc_mark_rsec of the file elflink.c of the component ld. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The patch is named f9978defb6fab0bd8583942d97c112b0932ac814. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Fix uninitialized array access for some pathnamesFor filenames that begin with . and are between 2 and 5 characters long,UDF charset conversion code would read uninitialized memory in theoutput buffer. The only practical impact is that the name may be prepended a"unification hash" when it is not actually needed but still it is goodto fix this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: mt8183: Add back SSPM related clocksThis reverts commit 860690a93ef23b567f781c1b631623e27190f101.On the MT8183, the SSPM related clocks were removed claiming a lack ofusage. This however causes some issues when the driver was converted tothe new simple-probe mechanism. This mechanism allocates enough spacefor all the clocks defined in the clock driver, not the highest indexin the DT binding. This leads to out-of-bound writes if their are holesin the DT binding or the driver (due to deprecated or unimplementedclocks). These errors can go unnoticed and cause memory corruption,leading to crashes in unrelated areas, or nothing at all. KASAN willdetect them.Add the SSPM related clocks back to the MT8183 clock driver to fullyimplement the DT binding. The SSPM clocks are for the power managementco-processor, and should never be turned off. They are marked as such.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: check slab-out-of-bounds in md_bitmap_get_counterIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()will return -EINVAL because 'page >= bitmap->pages', but the return valuewas not checked immediately in md_bitmap_get_counter() in order to set*blocks value and slab-out-of-bounds occurs.Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() andreturn directly if true.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Block switchdev mode when ADQ is active and vice versaADQ and switchdev are not supported simultaneously. Enabling both at thesame time can result in nullptr dereference.To prevent this, check if ADQ is active when changing devlink mode toswitchdev mode, and check if switchdev is active when enabling ADQ.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: fix time stamp counter initializationIf the gs_usb device driver is unloaded (or unbound) before theinterface is shut down, the USB stack first calls the structusb_driver::disconnect and then the struct net_device_ops::ndo_stopcallback.In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no moreRX'ed CAN frames are send from the USB device to the host. Later ings_can_close() a reset control message is send to each CAN channel toremove the controller from the CAN bus. In this race window the USBdevice can still receive CAN frames from the bus and internally queuethem to be send to the host.At least in the current version of the candlelight firmware, the queueof received CAN frames is not emptied during the reset command. Afterloading (or binding) the gs_usb driver, new URBs are submitted duringthe struct net_device_ops::ndo_open callback and the candlelightfirmware starts sending its already queued CAN frames to the host.However, this scenario was not considered when implementing thehardware timestamp function. The cycle counter/time counterinfrastructure is set up (gs_usb_timestamp_init()) after the USBs aresubmitted, resulting in a NULL pointer dereference iftimecounter_cyc2time() (via the call chain:gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() ->gs_usb_skb_set_timestamp()) is called too early.Move the gs_usb_timestamp_init() function before the URBs aresubmitted to fix this problem.For a comprehensive solution, we need to consider gs_usb devices withmore than 1 channel. The cycle counter/time counter infrastructure issetup per channel, but the RX URBs are per device. Once gs_can_open()of _a_ channel has been called, and URBs have been submitted, thegs_usb_receive_bulk_callback() can be called for _all_ availablechannels, even for channels that are not running, yet. As cyclecounter/time counter has not set up, this will again lead to a NULLpointer dereference.Convert the cycle counter/time counter from a "per channel" to a "perdevice" functionality. Also set it up, before submitting any URBs tothe device.Further in gs_usb_receive_bulk_callback(), don't process any URBs fornot started CAN channels, only resubmit the URB.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check for station first in client probeWhen probing a client, first check if we have it, and thencheck for the channel context, otherwise you can triggerthe warning there easily by probing when the AP isn't evenstarted yet. Since a client existing means the AP is alsooperating, we can then keep the warning.Also simplify the moved code a bit.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation before accessing cgx and lmacwith the addition of new MAC blocks like CN10K RPM and CN10KBRPM_USX, LMACs are noncontiguous and CGX blocks are alsononcontiguous. But during RVU driver initialization, the driveris assuming they are contiguous and trying to accesscgx or lmac with their id which is resulting in kernel panic.This patch fixes the issue by adding proper checks.[ 23.219150] pc : cgx_lmac_read+0x38/0x70[ 23.219154] lr : rvu_program_channels+0x3f0/0x498[ 23.223852] sp : ffff000100d6fc80[ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:000000000000005a[ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:fffffffffff0f000
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers/perf: hisi: Don't migrate perf to the CPU going to teardownThe driver needs to migrate the perf context if the current using CPU goingto teardown. By the time calling the cpuhp::teardown() callback thecpu_online_mask() hasn't updated yet and still includes the CPU going toteardown. In current driver's implementation we may migrate the contextto the teardown CPU and leads to the below calltrace:...[ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008[ 368.113699][ T932] Call trace:[ 368.116834][ T932] __switch_to+0x7c/0xbc[ 368.120924][ T932] __schedule+0x338/0x6f0[ 368.125098][ T932] schedule+0x50/0xe0[ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24[ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc[ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30[ 368.144573][ T932] mutex_lock+0x50/0x60[ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0[ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu][ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650[ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190[ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0[ 368.175099][ T932] kthread+0x108/0x13c[ 368.179012][ T932] ret_from_fork+0x10/0x18...Use function cpumask_any_but() to find one correct active cpu to fixesthis issue.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix deadloop issue on reading trace_pipeSoft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Through the vmcore, I found it's because in tracing_read_pipe(),ring_buffer_empty_cpu() found some buffer is not empty but then itcannot read anything due to "rb_num_of_entries() == 0" always true,Then it infinitely loop the procedure due to user buffer not beenfilled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }By some analyzing, I found that when resetting ringbuffer, the 'entries'of its pages are not all cleared (see rb_reset_cpu()). Then when reducingthe ringbuffer, and if some reduced pages exist dirty 'entries' data, theywill be added into 'cpu_buffer->overrun' (see rb_remove_pages()), whichcause wrong 'overrun' count and eventually cause the deadloop issue.To fix it, we need to clear every pages in rb_reset_cpu().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: Fix __bch_btree_node_alloc to make the failure behavior consistentIn some specific situations, the return value of __bch_btree_node_allocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.Fix it by initializing the return value in __bch_btree_node_alloc.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: move memblock_allow_resize() after linear mapping is readyThe initial memblock metadata is accessed from kernel image mapping. Theregions arrays need to "reallocated" from memblock and accessed throughlinear mapping to cover more memblock regions. So the resizing shouldnot be allowed until linear mapping is ready. Note that there arememblock allocations when building linear mapping.This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permitmemblock resizing until linear mapping is up").In following log, many memblock regions are reserved beforecreate_linear_mapping_page_table(). And then it triggered reallocationof memblock.reserved.regions and memcpy the old array in kernel imagemapping to the new array in linear mapping which caused a page fault.[ 0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6[ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000[ 0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae[ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c[ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128[ 0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff][ 0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000[ 0.000000] Oops [#1][ 0.000000] Modules linked in:[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66[ 0.000000] Hardware name: riscv-virtio,qemu (DT)[ 0.000000] epc : __memcpy+0x60/0xf8[ 0.000000] ra : memblock_double_array+0x192/0x248[ 0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0[ 0.000000] gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000[ 0.000000] t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60[ 0.000000] s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8[ 0.000000] a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000[ 0.000000] a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000[ 0.000000] s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00[ 0.000000] s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000[ 0.000000] s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000[ 0.000000] s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000[ 0.000000] t5 : 000000008f003000 t6 : ff600000ffffd000[ 0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f[ 0.000000] [
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- containerd > 0-0 (version in image is 1.7.27-150000.123.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: add cluster chain loop check for dirAn infinite loop may occur if the following conditions occur due tofile system corruption.(1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain.(2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory.(3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory.(4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation.(5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted.This commit adds checks to break the above infinite loop.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Destroy KFD debugfs after destroy KFD wqSince KFD proc content was moved to kernel debugfs, we can't destroy KFDdebugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq priorto kfd_debugfs_fini to fix a kernel NULL pointer problem. It happenswhen /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini butkfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry);tries to remove /sys/kernel/debug/kfd/proc/
while/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernelNULL pointer.(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not allow relocation of partially dropped subvolumes[BUG]There is an internal report that balance triggered transaction abort,with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]And btrfs check doesn't report anything wrong related to the extenttree.[CAUSE]The cause is a little complex, firstly the extent tree indeed doesn'thave the backref for 594526208.The extent tree only have the following two backrefs around that bytenron-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREEBut the such missing backref item is not an corruption on disk, as theoffending delayed ref belongs to subvolume 934, and that subvolume isbeing dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229And that offending tree block 594526208 is inside the dropped range ofthat subvolume. That explains why there is no backref item for thatbytenr and why btrfs check is not reporting anything wrong.But this also shows another problem, as btrfs will do all the orphansubvolume cleanup at a read-write mount.So half-dropped subvolume should not exist after an RW mount, andbalance itself is also exclusive to subvolume cleanup, meaning weshouldn't hit a subvolume half-dropped during relocation.The root cause is, there is no orphan item for this subvolume.In fact there are 5 subvolumes from around 2021 that have the sameproblem.It looks like the original report has some older kernels running, andcaused those zombie subvolumes.Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshotdeletion not triggered on mount") has long fixed the bug.[ENHANCEMENT]For repairing such old fs, btrfs-progs will be enhanced.Considering how delayed the problem will show up (at run delayed reftime) and at that time we have to abort transaction already, it is toolate.Instead here we reject any half-dropped subvolume for reloc tree at theearliest time, preventing confusion and extra time wasted on debuggingsimilar bugs.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: APEI: send SIGBUS to current task if synchronous memory error not recoveredIf a synchronous error is detected as a result of user-space processtriggering a 2-bit uncorrected error, the CPU will take a synchronouserror exception such as Synchronous External Abort (SEA) on Arm64. Thekernel will queue a memory_failure() work which poisons the relatedpage, unmaps the page, and then sends a SIGBUS to the process, so thata system wide panic can be avoided.However, no memory_failure() work will be queued when abnormalsynchronous errors occur. These errors can include situations likeinvalid PA, unexpected severity, no memory failure config support,invalid GUID section, etc. In such a case, the user-space process willtrigger SEA again. This loop can potentially exceed the platformfirmware threshold or even trigger a kernel hard lockup, leading to asystem reboot.Fix it by performing a force kill if no memory_failure() work is queuedfor synchronous errors.[ rjw: Changelog edits ]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: mdt_loader: Ensure we don't read past the ELF headerWhen the MDT loader is used in remoteproc, the ELF header is sanitizedbeforehand, but that's not necessary the case for other clients.Validate the size of the firmware buffer to ensure that we don't readpast the end as we iterate over the header. e_phentsize and e_shentsizeare validated as well, to ensure that the assumptions about step size inthe traversal are valid.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix validation of VF state in get resourcesVF state I40E_VF_STATE_ACTIVE is not the only state in whichVF is actually active so it should not be used to determineif a VF is allowed to obtain resources.Use I40E_VF_STATE_RESOURCES_LOADED that is set only ini40e_vc_get_vf_resources_msg() and cleared during reset.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Forbid FDB status change while nexthop is in a groupThe kernel forbids the creation of non-FDB nexthop groups with FDBnexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.However, as long as no routes are pointing to a non-FDB nexthop group,the kernel allows changing the type of a nexthop from FDB to non-FDB andvice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0This configuration is invalid and can result in a NPD [1] since FDBnexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1Fix by preventing nexthop FDB status change while the nexthop is in agroup: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.[1]BUG: kernel NULL pointer dereference, address: 00000000000003c0[...]Oops: Oops: 0000 [#1] SMPCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:fib_lookup_good_nhc+0x1e/0x80[...]Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before releaseThe fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can beNULL even after EPF initialization. Then it is prudent to check thatthey have non-NULL values before releasing the channels. Add the checksin pci_epf_test_clean_dma_chan().Without the checks, NULL pointer dereferences happen and they can leadto a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20[mani: trimmed the stack trace]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- libsodium23 > 0-0 (version in image is 1.0.18-150000.4.8.1).
-
Description: A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- rsync > 0-0 (version in image is 3.2.7-150600.3.11.1).
-
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-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
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.6 (version in image is 15.6-150600.37.2).
- openssh > 0-0 (version in image is 9.6p1-150600.6.29.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Rx page leak on multi-buffer framesThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for eachbuffer in the current frame. This function was introduced as part ofhandling multi-buffer XDP support in the ice driver.It works by iterating over the buffers from first_desc up to 1 plus thetotal number of fragments in the frame, cached from before the XDP programwas executed.If the hardware posts a descriptor with a size of 0, the logic used inice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get addedas fragments in ice_add_xdp_frag. Since the buffer isn't counted as afragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don'tcall ice_put_rx_buf().Because we don't call ice_put_rx_buf(), we don't attempt to re-use thepage or free it. This leaves a stale page in the ring, as we don'tincrement next_to_alloc.The ice_reuse_rx_page() assumes that the next_to_alloc has been incrementedproperly, and that it always points to a buffer with a NULL page. Sincethis function doesn't check, it will happily recycle a page over the topof the next_to_alloc buffer, losing track of the old page.Note that this leak only occurs for multi-buffer frames. Theice_put_rx_mbuf() function always handles at least one buffer, so asingle-buffer frame will always get handled correctly. It is not clearprecisely why the hardware hands us descriptors with a size of 0 sometimes,but it happens somewhat regularly with "jumbo frames" used by 9K MTU.To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() onall buffers between first_desc and next_to_clean. Borrow the logic of asimilar function in i40e used for this same purpose. Use the same logicalso in ice_get_pgcnts().Instead of iterating over just the number of fragments, use a loop whichiterates until the current index reaches to the next_to_clean element justpast the current frame. Unlike i40e, the ice_put_rx_mbuf() function doescall ice_put_rx_buf() on the last buffer of the frame indicating the end ofpacket.For non-linear (multi-buffer) frames, we need to take care when adjustingthe pagecnt_bias. An XDP program might release fragments from the tail ofthe frame, in which case that fragment page is already released. Onlyupdate the pagecnt_bias for the first descriptor and fragments stillremaining post-XDP program. Take care to only access the shared info forfragmented buffers, as this avoids a significant cache miss.The xdp_xmit value only needs to be updated if an XDP program is run, andonly once per packet. Drop the xdp_xmit pointer argument fromice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() functiondirectly. This avoids needing to pass the argument and avoids an extrabit-wise OR for each buffer in the frame.Move the increment of the ntc local variable to ensure its updated *before*all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logicrequires the index of the element just after the current frame.Now that we use an index pointer in the ring to identify the packet, we nolonger need to track or cache the number of fragments in the rx_ring.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ublk: fail to start device if queue setup is interruptedIn ublk_ctrl_start_dev(), if wait_for_completion_interruptible() isinterrupted by signal, queues aren't setup successfully yet, so wehave to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.Reported by German when working on qemu-storage-deamon which requiressingle thread ublk daemon.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Harden uplink netdev access against device unbindThe function mlx5_uplink_netdev_get() gets the uplink netdevicepointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice canbe removed and its pointer cleared when unbound from the mlx5_core.ethdriver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Ensure the pointer is valid before use by checking it for NULL. If itis valid, immediately call netdev_hold() to take a reference, andpreventing the netdevice from being freed while it is in use.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
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-development-tools-release == 15.6 (version in image is 15.6-150600.37.2).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.28.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libgnutls30 < 3.8.3-150600.4.12.1 (version in image is 3.8.3-150600.4.9.1).
-
Description: A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf trace: Really free the evsel->priv areaIn 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields inevsel->priv") it only was freeing if strcmp(evsel->tp_format->system,"syscalls") returned zero, while the corresponding initialization ofevsel->priv was being performed if it was _not_ zero, i.e. if the tpsystem wasn't 'syscalls'.Just stop looking for that and free it if evsel->priv was set, whichshould be equivalent.Also use the pre-existing evsel_trace__delete() function.This resolves these leaks, detected with: $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin ================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]#With this we plug all leaks with "perf trace sleep 1".
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- elfutils > 0-0 (version in image is 0.185-150400.5.3.1).
-
Description: A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject %p% format string in bprintf-like helpersstatic const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt));The above BPF program isn't rejected and causes a kernel warning atruntime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0This happens because bpf_bprintf_prepare skips over the second %,detected as punctuation, while processing %p. This patch fixes it bynot skipping over punctuation. %\x00 is then processed in the nextiteration and rejected.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probeUse devm_of_iomap() instead of of_iomap() to automatically handlethe unused ioremap region.If any error occurs, regions allocated by kzalloc() will leak,but using devm_kzalloc() instead will automatically free the memoryusing devm_kfree().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool()svc_create_memory_pool() is only called from stratix10_svc_drv_probe().Most of resources in the probe are managed, but not this memremap() call.There is also no memunmap() call in the file.So switch to devm_memremap() to avoid a resource leak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probeUse devm_of_iomap() instead of of_iomap() to automaticallyhandle the unused ioremap region. If any error occurs, regions allocated bykzalloc() will leak, but using devm_kzalloc() instead will automaticallyfree the memory using devm_kfree().Also, fix error handling of hws by adding unregister_hws label, whichunregisters remaining hws when iomap failed.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev/ep93xx-fb: Do not assign to struct fb_info.devDo not assing the Linux device to struct fb_info.dev. The call toregister_framebuffer() initializes the field to the fbdev device.Drivers should not override its value.Fixes a bug where the driver incorrectly decreases the hardwaredevice's reference counter and leaks the fbdev device.v2: * add Fixes tag (Dan)
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Don't leak some plane stateApparently no one noticed that mdp5 plane states leak like a sieveever since we introduced plane_state->commit refcount a few years agoin 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state tooearly by tracking commits, v3.")Fix it by using the right helpers.Patchwork: https://patchwork.freedesktop.org/patch/551236/
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: tegra: tegra124-emc: Fix potential memory leakThe tegra and tegra needs to be freed in the error handling path, otherwiseit will be leaked.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Unregister devlink params in case interface is downCurrently, in case an interface is down, mlx5 driver doesn'tunregister its devlink params, which leads to this WARN[1].Fix it by unregistering devlink params in that case as well.[1][ 295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc[ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61[ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023[ 295.543096 ] pc : devlink_free+0x174/0x1fc[ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core][ 295.561816 ] sp : ffff80000809b850[ 295.711155 ] Call trace:[ 295.716030 ] devlink_free+0x174/0x1fc[ 295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core][ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core][ 295.743534 ] auxiliary_bus_remove+0x2c/0x50[ 295.751893 ] __device_release_driver+0x19c/0x280[ 295.761120 ] device_release_driver+0x34/0x50[ 295.769649 ] bus_remove_device+0xdc/0x170[ 295.777656 ] device_del+0x17c/0x3a4[ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core][ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core][ 295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core][ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core][ 295.824998 ] shutdown+0xb0/0xd8 [mlx5_core][ 295.833439 ] pci_device_shutdown+0x3c/0xa0[ 295.841651 ] device_shutdown+0x170/0x340[ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0[ 295.857322 ] __arm64_sys_reboot+0x2c/0x40[ 295.865329 ] invoke_syscall+0x78/0x100[ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184[ 295.882392 ] do_el0_svc+0x30/0xac[ 295.889008 ] el0_svc+0x48/0x160[ 295.895278 ] el0t_64_sync_handler+0xa4/0x130[ 295.903807 ] el0t_64_sync+0x1a4/0x1a8[ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix leak in devfreq_dev_release()srcu_init_notifier_head() allocates resources that need to be releasedwith a srcu_cleanup_notifier_head() call.Reported by kmemleak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()The memory allocated in tb_queue_dp_bandwidth_request() needs to bereleased once the request is handled to avoid leaking it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Fix a leak in map_user_pages()If get_user_pages_fast() allocates some pages but not as many as wewanted, then the current code leaks those pages. Call put_page() onthe pages before returning.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-core: fix dev_pm_qos memleakCall dev_pm_qos_hide_latency_tolerance() in the error unwind patch toavoid following kmemleak:-blktests (master) # kmemleak-clear; ./check nvme/044;blktests (master) # kmemleak-scan ; kmemleak-shownvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124sunreferenced object 0xffff888110c46240 (size 96): comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloc_trace+0x25/0x90 [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100 [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfs_write+0xc5/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: Fix memory leak in devm_clk_notifier_register()devm_clk_notifier_register() allocates a devres resource for clknotifier but didn't register that to the device, so the notifier didn'tget unregistered on device detach and the allocated resource was leaked.Fix the issue by registering the resource through devres_add().This issue was found with kmemleak on a Chromebook.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clkWhen the best clk is searched, we iterate over all possible clk.If we find a better match, the previous one, if any, needs to be freed.If a better match has already been found, we still need to free the newone, otherwise it leaks.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()which can automatically release the related memory when the deviceor driver is removed or unloaded to avoid potential memory leak.In this case, iounmap(anatop_base) in line 427,433 are removedas manual release is not required.Besides, referring to clk-imx8mq.c, check the return code ofof_clk_add_hw_provider, if it returns negtive, print error infoand unregister hws, which makes the program more robust.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objectsIf a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`objects while evaluating the AMD LPS0 _DSM, there will be a memoryleak. Explicitly guard against this.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probeSmatch reports:drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.timer_baseaddr may have the problem of not being released after use,I replaced it with the devm_of_iomap() function and added the clk_put()function to cleanup the "clk_ce" and "clk_cs".
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knodeWhen u32_replace_hw_knode fails, we need to undo the tcf_bind_filteroperation done at u32_set_parms.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
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.6 (version in image is 15.6-150600.37.2).
- iproute2 > 0-0 (version in image is 6.4-150600.7.9.1).
-
Description: A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be exploited.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- libpcap1 > 0-0 (version in image is 1.10.4-150600.3.6.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()with the proper length instead of 0. This bug triggers this warningon a system with IOMMU enabled:WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170RIP: 0010:__iommu_dma_unmap+0x159/0x170Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00RSP: 0018:ff22d31181150c88 EFLAGS: 00010206RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0PKRU: 55555554Call Trace:? show_regs+0x6d/0x80? __warn+0x89/0x160? __iommu_dma_unmap+0x159/0x170? report_bug+0x17e/0x1b0? handle_bug+0x46/0x90? exc_invalid_op+0x18/0x80? asm_exc_invalid_op+0x1b/0x20? __iommu_dma_unmap+0x159/0x170? __iommu_dma_unmap+0xb3/0x170iommu_dma_unmap_page+0x4f/0x100dma_unmap_page_attrs+0x52/0x220? srso_alias_return_thunk+0x5/0xfbef5? xdp_return_frame+0x2e/0xd0bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]bnxt_poll+0xd3/0x1e0 [bnxt_en]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Allow CPU to reschedule while setting per-page memory attributesWhen running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),the host can experience CPU soft lockups when running an operation inkvm_vm_set_mem_attributes() to set memory attributes on the wholerange of guest memory.watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024RIP: 0010:xas_create+0x78/0x1f0Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87RSP: 0018:ffffad890a34b940 EFLAGS: 00000286RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0PKRU: 55555554Call Trace: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f5578d031bbCode: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bbRDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000bRBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0While looping through the range of memory setting the attributes,call cond_resched() to give the scheduler a chance to run a higherpriority task on the runqueue if necessary and avoid staying inkernel mode long enough to trigger the lockup.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Exit early on perf_mmap() failWhen perf_mmap() fails to allocate a buffer, it still invokes theevent_mapped() callback of the related event. On X86 this might increasethe perf_rdpmc_allowed reference counter. But nothing undoes this asperf_mmap_close() is never called in this case, which causes anotherreference count leak.Return early on failure to prevent that.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Fix surprise plug detection and recoveryThe existing PowerNV hotplug code did not handle surprise plug eventscorrectly, leading to a complete failure of the hotplug system after deviceremoval and a required reboot to detect new devices.This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot.Issue the appropriate unfreeze and rescan commands on hotplug events,and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.[bhelgaas: tidy comments]
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: increase scan_ies_len for S1GCurrently the S1G capability element is not taken into accountfor the scan_ies_len, which leads to a buffer length validationfailure in ieee80211_prep_hw_scan() and subsequent WARN in__ieee80211_start_scan(). This prevents hw scanning from functioning.To fix ensure we accommodate for the S1G capability length.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add max boundary check for VF filtersThere is no check for max filters that VF can request. Add it.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_IDPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zerounique ID.```Each Unit and Terminal within the video function is assigned a uniqueidentification number, the Unit ID (UID) or Terminal ID (TID), contained inthe bUnitID or bTerminalID field of the descriptor. The value 0x00 isreserved for undefined ID,```If we add a new entity with id 0 or a duplicated ID, it will be markedas UVC_INVALID_ENTITY_ID.In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Requireentities to have a non-zero unique ID"), we ignored all the invalid units,this broke a lot of non-compatible cameras. Hopefully we are more luckythis time.This also prevents some syzkaller reproducers from triggering warnings dueto a chain of entities referring to themselves. In one particular case, anOutput Unit is connected to an Input Unit, both with the same ID of 1. Butwhen looking up for the source ID of the Output Unit, that same entity isfound instead of the input entity, which leads to such warnings.In another case, a backward chain was considered finished as the source IDwas 0. Later on, that entity was found, but its pads were not valid.Here is a sample stack trace for one of those cases.[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd[ 20.830206] usb 1-1: Using ep0 maxpacket: 8[ 20.833501] usb 1-1: config 0 descriptor??[ 21.038518] usb 1-1: string descriptor 0 read error: -71[ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201)[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized![ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized![ 21.042218] ------------[ cut here ]------------[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0[ 21.043195] Modules linked in:[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 21.044639] Workqueue: usb_hub_wq hub_event[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0[ 21.051136] PKRU: 55555554[ 21.051331] Call Trace:[ 21.051480] [ 21.051611] ? __warn+0xc4/0x210[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0[ 21.052252] ? report_bug+0x11b/0x1a0[ 21.052540] ? trace_hardirqs_on+0x31/0x40[ 21.052901] ? handle_bug+0x3d/0x70[ 21.053197] ? exc_invalid_op+0x1a/0x50[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20[ 21.053924] ? media_create_pad_link+0x91/0x2e0[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0[ 21.054834] ? media_create_pad_link+0x91/0x2e0[ 21.055131] ? _raw_spin_unlock+0x1e/0x40[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210[ 21.055837] uvc_mc_register_entities+0x358/0x400[ 21.056144] uvc_register_chains+0x1---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfs: Don't leak disconnected dentries on umountWhen user calls open_by_handle_at() on some inode that is not cached, wewill create disconnected dentry for it. If such dentry is a directory,exportfs_decode_fh_raw() will then try to connect this dentry to thedentry tree through reconnect_path(). It may happen for various reasons(such as corrupted fs or race with rename) that the call tolookup_one_unlocked() in reconnect_one() will fail to find the dentry weare trying to reconnect and instead create a new dentry under theparent. Now this dentry will not be marked as disconnected although theparent still may well be disconnected (at least in case thisinconsistency happened because the fs is corrupted and .. doesn't pointto the real parent directory). This creates inconsistency indisconnected flags but AFAICS it was mostly harmless. At least untilcommit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")which removed adding of most disconnected dentries to sb->s_anon list.Thus after this commit cleanup of disconnected dentries implicitelyrelies on the fact that dput() will immediately reclaim such dentries.However when some leaf dentry isn't marked as disconnected, as in thescenario described above, the reclaim doesn't happen and the dentriesare "leaked". Memory reclaim can eventually reclaim them but otherwisethey stay in memory and if umount comes first, we hit infamous "Busyinodes after unmount" bug. Make sure all dentries created under adisconnected parent are marked as disconnected as well.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicastsyzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.This is the sequence of events that leads to the warning:rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb);}rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done}rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission}rtl8150_set_multicast being the ndo_set_rx_mode callback should not becalling netif_stop_queue and notif_start_queue as these handleTX queue synchronization.The net core function dev_set_rx_mode handles the synchronizationfor rtl8150_set_multicast making it safe to remove these locks.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.58.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.
Packages affected:
- sle-module-python3-release == 15.6 (version in image is 15.6-150600.37.2).
- python311 < 3.11.14-150600.3.38.1 (version in image is 3.11.13-150600.3.35.2).
-
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.6 (version in image is 15.6-150600.37.2).
- gettext-runtime > 0-0 (version in image is 0.21.1-150600.3.3.2).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- curl > 0-0 (version in image is 8.14.1-150600.4.28.1).
-
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.6 (version in image is 15.6-150600.37.2).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix igb_down hung on surprise removalIn a setup where a Thunderbolt hub connects to Ethernet and a displaythrough USB Type-C, users may experience a hung task timeout when theyremove the cable between the PC and the Thunderbolt hub.This is because the igb_down function is called multiple times whenthe Thunderbolt hub is unplugged. For example, the igb_io_error_detectedtriggers the first call, and the igb_remove triggers the second call.The second call to igb_down will block at napi_synchronize.Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30In this case, igb_io_error_detected detaches the network interfaceand requests a PCIE slot reset, however, the PCIE reset callback isnot being invoked and thus the Ethernet connection breaks down.As the PCIE error in this case is a non-fatal one, requesting aslot reset can be avoided.This patch fixes the task hung issue and preserves Ethernetconnection by ignoring non-fatal PCIE errors.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix refcount underflow in error pathFix a refcount underflow problem reported by syzbot that can happenwhen a system is running out of memory. If xp_alloc_tx_descs() fails,and it can only fail due to not having enough memory, then the errorpath is triggered. In this error path, the refcount of the pool isdecremented as it has incremented before. However, the reference tothe pool in the socket was not nulled. This means that when the socketis closed later, the socket teardown logic will think that there is apool attached to the socket and try to decrease the refcount again,leading to a refcount underflow.I chose this fix as it involved adding just a single line. Anotheroption would have been to move xp_get_pool() and the assignment ofxs->pool to after the if-statement and using xs_umem->pool instead ofxs->pool in the whole if-statement resulting in somewhat simpler code,but this would have led to much more churn in the code base perhapsmaking it harder to backport.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: separate no-async decryption request handling from asyncIf we're not doing async, the handling is much simpler. There's noreference counting, we just need to wait for the completion to wake usup and return its result.We should preferably also use a separate crypto_wait. I'm not seeing aUAF as I did in the past, I think aec7961916f3 ("tls: fix race betweenasync notify and socket close") took care of it.This will make the next fix easier.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfd_malloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).
-
Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- elfutils > 0-0 (version in image is 0.185-150400.5.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()Update struct hid_descriptor to better reflect the mandatory andoptional parts of the HID Descriptor as per USB HID 1.11 specification.Note: the kernel currently does not parse any optional HID classdescriptors, only the mandatory report descriptor.Update all references to member element desc[0] to rpt_desc.Add test to verify bLength and bNumDescriptors values are valid.Replace the for loop with direct access to the mandatory HID classdescriptor member for the report descriptor. This eliminates thepossibility of getting an out-of-bounds fault.Add a warning message if the HID descriptor contains any unsupportedoptional HID class descriptors.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
- sle-module-python3-release == 15.6 (version in image is 15.6-150600.37.2).
- python311 < 3.11.14-150600.3.38.1 (version in image is 3.11.13-150600.3.35.2).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- binutils > 0-0 (version in image is 2.43-150100.7.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Fix memory leak in acpi_buffer->pointerThere are memory leaks reported by kmemleak:...unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight]...The ACPI buffer memory (buf.pointer) should be freed. But the bufferis also used after returning from acpi_get_dsd_graph().Move the temporary variables buf to acpi_coresight_parse_graph(),and free it before the function return to prevent memory leak.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject unhashed sockets in bpf_sk_assignThe semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk)That is, the sk is not consumed by bpf_sk_assign. The functiontherefore needs to make sure that sk lives long enough to beconsumed from __inet_lookup_skb. The path through the stack for aTCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sockThe existing helper takes advantage of the fact that everythinghappens in the same RCU critical section: for sockets withSOCK_RCU_FREE set bpf_sk_assign never takes a reference.skb_steal_sock then checks SOCK_RCU_FREE again and does sock_putif necessary.This approach assumes that SOCK_RCU_FREE is never set on a skbetween bpf_sk_assign and skb_steal_sock, but this invariant isviolated by unhashed UDP sockets. A new UDP socket is createdin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is onlyadded in udp_lib_get_port() which happens when a socket is bound.When bpf_sk_assign was added it wasn't possible to access unhashedUDP sockets from BPF, so this wasn't a problem. This changedin commit 0c48eefae712 ("sock_map: Lift socket state restrictionfor datagram sockets"), but the helper wasn't adjusted accordingly.The following sequence of events will therefore lead to a refcountleak:1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount.3. bind() or connect() the socket, setting SOCK_RCU_FREE.4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE.5. tcp_v4_rcv() skips sock_put().Fix the problem by rejecting unhashed sockets in bpf_sk_assign().This matches the behaviour of __inet_lookup_skb which is ultimatelythe goal of bpf_sk_assign().
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function'unregister_nvdimm_pmu'.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Don't balance task to its current running CPUWe've run into the case that the balancer tries to balance a migrationdisabled task and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]---Further investigation shows that the warning is superfluous, the migrationdisabled task is just going to be migrated to its current running CPU.This is because that on load balance if the dst_cpu is not allowed by thetask, we'll re-select a new_dst_cpu as a candidate. If no task can bebalanced to dst_cpu we'll try to balance the task to the new_dst_cpuinstead. In this case when the migration disabled task is not on CPU itonly allows to run on its current CPU, load balance will select itscurrent CPU as new_dst_cpu and later triggers the warning above.The new_dst_cpu is chosen from the env->dst_grpmask. Currently itcontains CPUs in sched_group_span() and if we have overlapped groups it'spossible to run into this case. This patch makes env->dst_grpmask ofgroup_balance_mask() which exclude any CPUs from the busiest group andsolve the issue. For balancing in a domain with no overlapped groupsthe behaviour keeps same as before.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profileCallers of `btrfs_reduce_alloc_profile` expect it to return exactlyone allocation profile flag, and failing to do so may ultimatelyresult in a WARN_ON and remount-ro when allocating new blocks, likethe below transaction abort on 6.1.`btrfs_reduce_alloc_profile` has two ways of determining the profile,first it checks if a conversion balance is currently running anduses the profile we're converting to. If no balance is currentlyrunning, it returns the max-redundancy profile which at least oneblock in the selected block group has.This works by simply checking each known allocation profile bit inredundancy order. However, `btrfs_reduce_alloc_profile` has not beenupdated as new flags have been added - first with the `DUP` profileand later with the RAID1C34 profiles.Because of the way it checks, if we have blocks with differentprofiles and at least one is known, that profile will be selected.However, if none are known we may return a flag set with multipleallocation profiles set.This is currently only possible when a balance from one of the threeunhandled profiles to another of the unhandled profiles is canceledafter allocating at least one block using the new profile.In that case, a transaction abort like the below will occur and thefilesystem will need to be mounted with -o skip_balance to get itmounted rw again (but the balance cannot be resumed without asimilar abort). [770.648] ------------[ cut here ]------------ [770.648] BTRFS: Transaction aborted (error -22) [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0 [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test) [770.648] MSR: 9000000002029033 CR: 28848282 XER: 20040000 [770.648] CFAR: c000000000135110 IRQMASK: 0 GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026 GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027 GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8 GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000 GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001 GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800 GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001 [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] [770.648] Call Trace: [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable) [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs] [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs] [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs] [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs] [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs] [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs] [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs] [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs] [770.648] [---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Remove unused nvme_ls_waitq wait queueSystem crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_upgets called for uninitialized wait queue sp->nvme_ls_waitq. qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0 qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removedpreviously in the commits tagged Fixed: below.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:start_kernel: Add __no_stack_protector function attributeBack during the discussion ofcommit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")we discussed the need for a function attribute to control the omissionof stack protectors on a per-function basis; at the time Clang hadsupport for no_stack_protector but GCC did not. This was fixed ingcc-11. Now that the function attribute is available, let's start usingit.Callers of boot_init_stack_canary need to use this function attributeunless they're compiled with -fno-stack-protector, otherwise the canarystored in the stack slot of the caller will differ upon the call toboot_init_stack_canary. This will lead to a call to __stack_chk_fail()then panic.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix handling of lrbp->cmdufshcd_queuecommand() may be called two times in a row for a SCSI commandbefore it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.See also scsi_send_eh_cmnd().This commit prevents that the following appears if a command times out:WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: check 'jh->b_transaction' before removing it from checkpointFollowing process will corrupt ext4 image:Step 1:jbd2_journal_commit_transaction __jbd2_journal_insert_checkpoint(jh, commit_transaction) // Put jh into trans1->t_checkpoint_list journal->j_checkpoint_transactions = commit_transaction // Put trans1 into journal->j_checkpoint_transactionsStep 2:do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirty,set jbd dirty __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2Step 3:drop_cache journal_shrink_one_cp_list jbd2_journal_try_remove_checkpoint if (!trylock_buffer(bh)) // lock bh, true if (buffer_dirty(bh)) // buffer is not dirty __jbd2_journal_remove_checkpoint(jh) // remove jh from trans1->t_checkpoint_listStep 4:jbd2_log_do_checkpoint trans1 = journal->j_checkpoint_transactions // jh is not in trans1->t_checkpoint_list jbd2_cleanup_journal_tail(journal) // trans1 is doneStep 5: Power cut, trans2 is not committed, jh is lost in next mounting.Fix it by checking 'jh->b_transaction' before remove it from checkpoint.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") theperf_sample_event_took() function was added to report time spent inoverflow interrupts. If the interrupt takes too long, the perf frameworkwill lower the sysctl_perf_event_sample_rate and max_samples_per_tick.When hwc->interrupts is larger than max_samples_per_tick, thehwc->interrupts will be set to MAX_INTERRUPTS, and events will bethrottled within the __perf_event_account_interrupt() function.However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update thePERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()function to avoid throttling. When the perf framework unthrottled the eventin the timer interrupt handler, it triggers riscv_pmu_start() functionand causes a WARN_ON_ONCE() warning, as shown below: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e Modules linked in: CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1 Hardware name: SiFive (DT) epc : riscv_pmu_start+0x7c/0x8e ra : riscv_pmu_start+0x28/0x8e epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0 gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0 t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720 s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000 a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030 s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00 s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000 s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340 s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796 t5 : 0000000700000000 t6 : ffffaf8005269870 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [] riscv_pmu_start+0x7c/0x8e [] perf_adjust_freq_unthr_context+0x15e/0x174 [] perf_event_task_tick+0x88/0x9c [] scheduler_tick+0xfe/0x27c [] update_process_times+0x9a/0xba [] tick_sched_handle+0x32/0x66 [] tick_sched_timer+0x64/0xb0 [] __hrtimer_run_queues+0x156/0x2f4 [] hrtimer_interrupt+0xe2/0x1fe [] riscv_timer_interrupt+0x38/0x42 [] handle_percpu_devid_irq+0x90/0x1d2 [] generic_handle_domain_irq+0x28/0x36After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,they don't call *_pmu_stop() to update with PERF_HES_STOPPED flagafter perf_event_overflow() function nor do they add PERF_HES_STOPPEDflag checking in *_pmu_start() which don't cause this warning.Thus, it's recommended to remove this unnecessary check inriscv_pmu_start() function to prevent this warning.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.55.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as critical. Affected by this issue is the function bfd_putl64 of the file bfd/libbfd.c of the component ld. The manipulation leads to memory corruption. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer explains, that "[t]his bug has been fixed at some point between the 2.43 and 2.44 releases".
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu-qcom: Add SM6115 MDSS compatibleAdd the SM6115 MDSS compatible to clients compatible list, as it alsoneeds that workaround.Without this workaround, for example, QRB4210 RB2 which is based onSM4250/SM6115 generates a lot of smmu unhandled context faults duringboot:arm_smmu_context_fault: 116854 callbacks suppressedarm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420and also failed initialisation of lontium lt9611uxc, gpu and dpu isobserved:(binding MDSS components triggered by lt9611uxc have failed) ------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix the setting of capabilities when automounting a new filesystemCapabilities cannot be inherited when we cross into a new filesystem.They need to be reset to the minimal defaults, and then probed foragain.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Remove WARN_ON for device endpoint command timeoutsThis commit addresses a rarely observed endpoint command timeoutwhich causes kernel panic due to warn when 'panic_on_warn' is enabledand unnecessary call trace prints when 'panic_on_warn' is disabled.It is seen during fast software-controlled connect/disconnect testcases.The following is one such endpoint command timeout that we observed:1. Connect =======->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd2. Disconnect ==========->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmdIn the issue scenario, in Exynos platforms, we observed that controltransfers for the previous connect have not yet been completed and endtransfer command sent as a part of the disconnect sequence andprocessing of USB_ENDPOINT_HALT feature request from the host timeout.This maybe an expected scenario since the controller is processing EPcommands sent as a part of the previous connect. It maybe better toremove WARN_ON in all places where device endpoint commands are sent toavoid unnecessary kernel panic due to warn.
Packages affected:
- sle-module-public-cloud-release == 15.6 (version in image is 15.6-150600.37.2).
- kernel-azure < 6.4.0-150600.8.52.1 (version in image is 6.4.0-150600.8.48.1).
-
Description: A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.
Packages affected:
- sle-module-basesystem-release == 15.6 (version in image is 15.6-150600.37.2).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 15.6 (version in image is 15.6-150600.64.3.1).
- elfutils > 0-0 (version in image is 0.185-150400.5.3.1).