-
Description: The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).
-
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.5 (version in image is 15.5-150500.43.2).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability.The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Memory safety bugs present in Firefox 141 and Thunderbird 141. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 142 and Thunderbird < 142.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- bind-utils < 9.16.50-150500.8.32.1 (version in image is 9.16.50-150500.8.27.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- bind-utils < 9.16.50-150500.8.32.1 (version in image is 9.16.50-150500.8.27.1).
-
Description: An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.1).
-
Description: Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- python3-Jinja2 > 0-0 (version in image is 2.10.1-150000.3.21.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: avoid potential out-of-bound access in fill_frame_info()syzbot is able to feed a packet with 14 bytes, pretendingit is a vlan one.Since fill_frame_info() is relying on skb->mac_len already,extend the check to cover this case.BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Propagate error from htab_lock_bucket() to userspaceIn __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns-EBUSY, it will go to next bucket. Going to next bucket may not onlyskip the elements in current bucket silently, but also incurout-of-bound memory access or expose kernel memory to userspace ifcurrent bucket_cnt is greater than bucket_size or zero.Fixing it by stopping batch operation and returning -EBUSY whenhtab_lock_bucket() fails, and the application can retry or skip the busybatch as needed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-core: Fix double free in dvb_register_device()In function dvb_register_device() -> dvb_register_media_device() ->dvb_create_media_entity(), dvb->entity is allocated and initialized. Ifthe initialization fails, it frees the dvb->entity, and return an errorcode. The caller takes the error code and handles the error by callingdvb_media_device_free(), which unregisters the entity and frees thefield again if it is not NULL. As dvb->entity may not NULLed indvb_create_media_entity() when the allocation of dvbdev->pad fails, adouble free may occur. This may also cause an Use After free inmedia_device_unregister_entity().Fix this by storing NULL to dvb->entity when it is freed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Delay the unmapping of the bufferOn WCN3990, we are seeing a rare scenario where copy engine hardware issending a copy complete interrupt to the host driver while stillprocessing the buffer that the driver has sent, this is leading into anSMMU fault triggering kernel panic. This is happening on copy enginechannel 3 (CE3) where the driver normally enqueues WMI commands to thefirmware. Upon receiving a copy complete interrupt, host driver willimmediately unmap and frees the buffer presuming that hardware hasprocessed the buffer. In the issue case, upon receiving copy completeinterrupt, host driver will unmap and free the buffer but since hardwareis still accessing the buffer (which in this case got unmapped inparallel), SMMU hardware will trigger an SMMU fault resulting in akernel panic.In order to avoid this, as a work around, add a delay before unmappingthe copy engine source DMA buffer. This is conditionally done forWCN3990 and only for the CE3 channel where issue is seen.Below is the crash signature:wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandledcontext fault: fsr=0x402, iova=0x7fdfd8ac0,fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandledcontext fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal errorreceived: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149remoteproc remoteproc0: crash detected in4080000.remoteproc: type fatal error <3> remoteproc remoteproc0:handling crash #1 in 4080000.remoteprocpc : __arm_lpae_unmap+0x500/0x514lr : __arm_lpae_unmap+0x4bc/0x514sp : ffffffc011ffb530x29: ffffffc011ffb590 x28: 0000000000000000x27: 0000000000000000 x26: 0000000000000004x25: 0000000000000003 x24: ffffffc011ffb890x23: ffffffa762ef9be0 x22: ffffffa77244ef00x21: 0000000000000009 x20: 00000007fff7c000x19: 0000000000000003 x18: 0000000000000000x17: 0000000000000004 x16: ffffffd7a357d9f0x15: 0000000000000000 x14: 00fd5d4fa7ffffffx13: 000000000000000e x12: 0000000000000000x11: 00000000ffffffff x10: 00000000fffffe00x9 : 000000000000017c x8 : 000000000000000cx7 : 0000000000000000 x6 : ffffffa762ef9000x5 : 0000000000000003 x4 : 0000000000000004x3 : 0000000000001000 x2 : 00000007fff7c000x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:__arm_lpae_unmap+0x500/0x514__arm_lpae_unmap+0x4bc/0x514__arm_lpae_unmap+0x4bc/0x514arm_lpae_unmap_pages+0x78/0xa4arm_smmu_unmap_pages+0x78/0x104__iommu_unmap+0xc8/0x1e4iommu_unmap_fast+0x38/0x48__iommu_dma_unmap+0x84/0x104iommu_dma_free+0x34/0x50dma_free_attrs+0xa4/0xd0ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c[ath10k_core]ath10k_halt+0x11c/0x180 [ath10k_core]ath10k_stop+0x54/0x94 [ath10k_core]drv_stop+0x48/0x1c8 [mac80211]ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c[mac80211]__dev_open+0xb4/0x174__dev_change_flags+0xc4/0x1dcdev_change_flags+0x3c/0x7cdevinet_ioctl+0x2b4/0x580inet_ioctl+0xb0/0x1b4sock_do_ioctl+0x4c/0x16ccompat_ifreq_ioctl+0x1cc/0x35ccompat_sock_ioctl+0x110/0x2ac__arm64_compat_sys_ioctl+0xf4/0x3e0el0_svc_common+0xb4/0x17cel0_svc_compat_handler+0x2c/0x58el0_svc_compat+0x8/0x2cTested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: validate the extent length for uncompressed pclusterssyzkaller reported a KASAN use-after-free:https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2The referenced fuzzed image actually has two issues: - m_pa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.The first issue has already been addressed. This patch addressesthe second issue by checking the extent length validity.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOTIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumedto be either root or ingress. This assumption is bogus since it's validto create egress qdiscs with major handle ffff:Budimir Markovic found that for qdiscs like DRR that maintain an activeclass list, it will cause a UAF with a dangling class pointer.In 066a3b5b2346, the concern was to avoid iterating over the ingressqdisc since its parent is itself. The proper fix is to stop when parentTC_H_ROOT is reached because the only way to retrieve ingress is when ahierarchy which does not contain a ffff: major handle call intoqdisc_lookup with TC_H_MAJ(TC_H_ROOT).In the scenario where major ffff: is an egress qdisc in any of the treelevels, the updates will also propagate to TC_H_ROOT, which then theiteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: add missing range check in bitmap_ip_uadtWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,the values of ip and ip_to are slightly swapped. Therefore, the range checkfor ip should be done later, but this part is missing and it seems that thevulnerability occurs.So we should add missing range checks and remove unnecessary range checks.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp's timer handler function causes problems.To fix this problem, let's hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the 'NextCapability Offset' field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet6: do not leave a dangling sk pointer in inet6_create()sock_init_data() attaches the allocated sk pointer to the provided sockobject. If inet6_create() fails later, the sk object is released, but thesock object retains the dangling sk pointer, which may cause use-after-freelater.Clear the sock sk pointer on error.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet: do not leave a dangling sk pointer in inet_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If inet_create() fails later, the sk object is freed, but thesock object retains the dangling pointer, which may create use-after-freelater.Clear the sk pointer in the sock object on error.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()Syzbot reported that when searching for records in a directory where theinode's i_size is corrupted and has a large value, memory access outsidethe folio/page range may occur, or a use-after-free bug may be detected ifKASAN is enabled.This is because nilfs_last_byte(), which is called by nilfs_find_entry()and others to calculate the number of valid bytes of directory data in apage from i_size and the page index, loses the upper 32 bits of the 64-bitsize information due to an inappropriate type of local variable to whichthe i_size value is assigned.This caused a large byte offset value due to underflow in the end addresscalculation in the calling nilfs_find_entry(), resulting in memory accessthat exceeds the folio/page size.Fix this issue by changing the type of the local variable causing the bitloss from "unsigned int" to "u64". The return value of nilfs_last_byte()is also of type "unsigned int", but it is truncated so as not to exceedPAGE_SIZE and no bit loss occurs, so no change is required.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix LED ID check in led_tg_check()Syzbot has reported the following BUG detected by KASAN:BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70Read of size 1 at addr ffff8881022da0c8 by task repro/5879...Call Trace: dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... Since an invalid (without '\0' byte at all) byte sequence may be passedfrom userspace, add an extra check to ensure that such a sequence isrejected as possible ID and so never passed to 'kstrdup()' and further.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: defer final 'struct net' free in netns dismantleIlya reported a slab-use-after-free in dst_destroy [1]Issue is in xfrm6_net_init() and xfrm4_net_init() :They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.But net structure might be freed before all the dst callbacks arecalled. So when dst_destroy() calls later :if (dst->ops->destroy) dst->ops->destroy(dst);dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.See a relevant issue fixed in :ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")A fix is to queue the 'struct net' to be freed after oneanother cleanup_net() round (and existing rcu_barrier())[1]BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0Dec 03 05:46:18 kernel:CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:124)print_address_description.constprop.0 (mm/kasan/report.c:378)? dst_destroy (net/core/dst.c:112)print_report (mm/kasan/report.c:489)? dst_destroy (net/core/dst.c:112)? kasan_addr_to_slab (mm/kasan/common.c:37)kasan_report (mm/kasan/report.c:603)? dst_destroy (net/core/dst.c:112)? rcu_do_batch (kernel/rcu/tree.c:2567)dst_destroy (net/core/dst.c:112)rcu_do_batch (kernel/rcu/tree.c:2567)? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)rcu_core (kernel/rcu/tree.c:2825)handle_softirqs (kernel/softirq.c:554)__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)irq_exit_rcu (kernel/softirq.c:651)sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835dR10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)? cpuidle_idle_call (kernel/sched/idle.c:186)default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)cpuidle_idle_call (kernel/sched/idle.c:186)? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)do_idle (kernel/sched/idle.c:326)cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452)common_startup_64 (arch/x86/kernel/head_64.S:414) Dec 03 05:46:18 kernel:Allocated by task 12184:kasan_save_stack (mm/kasan/common.c:48)kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)create_new_namespaces---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:rpl: Fix use-after-free in rpl_do_srh_inline().Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggersthe splat below [0].rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it afterskb_cow_head(), which is illegal as the header could be freed then.Let's fix it by making oldhdr to a local struct instead of a pointer.[0]:[root@fedora net]# ./lwt_dst_cache_ref_loop.sh...TEST: rpl (input)[ 57.631529] ==================================================================BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)Read of size 40 at addr ffff888122bf96d8 by task ping6/1543CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)RIP: 0033:0x7f68cffb2a06Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001cR10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).
-
Description: An undocumented and unsafe feature in the PLY (Python Lex-Yacc) library 3.11 allows Remote Code Execution (RCE) via the `picklefile` parameter in the `yacc()` function. This parameter accepts a `.pkl` file that is deserialized with `pickle.load()` without validation. Because `pickle` allows execution of embedded code via `__reduce__()`, an attacker can achieve code execution by passing a malicious pickle file. The parameter is not mentioned in official documentation or the GitHub repository, yet it is active in the PyPI version. This introduces a stealthy backdoor and persistence risk.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3-ply > 0-0 (version in image is 3.10-150000.3.8.1).
-
Description: Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc.Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.95.1).
-
Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools < 2.70.5-150400.3.29.1 (version in image is 2.70.5-150400.3.23.1).
-
Description: When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).
-
Description: A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxslt1 > 0-0 (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.5 (version in image is 15.5-150500.61.4.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:ipvs: fix ipv4 null-ptr-deref in route error pathThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()without ensuring skb->dev is set, leading to a NULL pointer dereferencein fib_compute_spec_dst() when ipv4_link_failure() attempts to sendICMP destination unreachable messages.The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip optionsin ipv4_link_failure") started calling __ip_options_compile() fromipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()which dereferences skb->dev. An attempt was made to fix the NULL skb->devdereference in commit 0113d9c9d1cc ("ipv4: fix null-deref inipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)dereference by using a fallback device. The fix was incomplete becausefib_compute_spec_dst() later in the call chain still accesses skb->devdirectly, which remains NULL when IPVS calls dst_link_failure().The crash occurs when:1. IPVS processes a packet in NAT mode with a misconfigured destination2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route3. The error path calls dst_link_failure(skb) with skb->dev == NULL4. ipv4_link_failure() -> ipv4_send_dest_unreach() -> __ip_options_compile() -> fib_compute_spec_dst()5. fib_compute_spec_dst() dereferences NULL skb->devApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fixipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev beforecalling dst_link_failure().KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285Call Trace: spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()There exists a kernel oops caused by a BUG_ON(nhead < 0) atnet/core/skbuff.c:2232 in pskb_expand_head().This bug is triggered as part of the calipso_skbuff_setattr()routine when skb_cow() is passed headroom > INT_MAX(i.e. (int)(skb_headroom(skb) + len_delta) < 0).The root cause of the bug is due to an implicit integer cast in__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensurethat delta = headroom - skb_headroom(skb) is never negative, otherwisewe will trigger a BUG_ON in pskb_expand_head(). However, ifheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, deltabecomes negative, and pskb_expand_head() is passed a negative value fornhead.Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()by only using skb_cow() to grow headroom.PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verfA zero length gss_token results in pages == 0 and in_token->pages[0]is NULL. The code unconditionally evaluatespage_address(in_token->pages[0]) for the initial memcpy, which candereference NULL even when the copy length is 0. Guard the firstmemcpy so it only runs when length > 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).
-
Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.2, a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. This vulnerability is fixed in 0.6.2.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3-pyasn1 > 0-0 (version in image is 0.4.2-150000.3.8.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:libceph: prevent potential out-of-bounds writes in handle_auth_session_key()The len field originates from untrusted network packets. Boundarychecks have been added to prevent potential out-of-bounds writes whendecrypting the connection secret or processing service tickets.[ idryomov: changelog ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free of kernel socket in cleanup_bearer().syzkaller reported a use-after-free of UDP kernel socketin cleanup_bearer() without repro. [0][1]When bearer_disable() calls tipc_udp_disable(), cleanupof the UDP kernel socket is deferred by work callingcleanup_bearer().tipc_exit_net() waits for such works to finish by checkingtipc_net(net)->wq_count. However, the work decrements thecount too early before releasing the kernel socket,unblocking cleanup_net() and resulting in use-after-free.Let's move the decrement after releasing the socket incleanup_bearer().[0]:ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830[1]:BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfaHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: events cleanup_bearer
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools < 2.70.5-150400.3.29.1 (version in image is 2.70.5-150400.3.23.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.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: idle: Check acpi_fetch_acpi_dev() return valueThe return value of acpi_fetch_acpi_dev() could be NULL, which wouldcause a NULL pointer dereference to occur in acpi_device_hid().[ rjw: Subject and changelog edits, added empty line after if () ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()Syzkaller reports a null-ptr-deref bug as follows:======================================================KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380[...]Call Trace: vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [inline] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ======================================================According to commit "vfs: parse: deal with zero length string value",kernel will set the param->string to null pointer in vfs_parse_fs_string()if fs string has zero length.Yet the problem is that, hugetlbfs_parse_param() will dereference theparam->string, without checking whether it is a null pointer. To be morespecific, if hugetlbfs_parse_param() parses an illegal mount parameter,such as "size=,", kernel will constructs struct fs_parameter with nullpointer in vfs_parse_fs_string(), then passes this struct fs_parameter tohugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.This patch solves it by adding sanity check on param->stringin hugetlbfs_parse_param().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block, bfq: fix possible uaf for 'bfqq->bic'Our test report a uaf for 'bfqq->bic' in 5.10:==================================================================BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups")changes that move process to a new cgroup will allocate a new bfqq touse, however, the old bfqq and new bfqq can point to the same bic:1) Initial state, two process with io in the same cgroup.Process 1 Process 2 (BIC1) (BIC2) | ^ | ^ | | | | V | V | bfqq1 bfqq22) bfqq1 is merged to bfqq2.Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop)3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | ^ | | V | bfqq2(coop)4) Before IOA is completed, move Process 2 to another cgroup and issue io.Process 2 (BIC2) ^ |\--------------\ | V bfqq2 bfqq3Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2.If all the requests are completed, and Process 2 exit, BIC2 will befreed while there is no guarantee that bfqq2 will be freed before BIC2.Fix the problem by clearing bfqq->bic while bfqq is detached from bic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mrp: introduce active flags to prevent UAF when applicant uninitThe caller of del_timer_sync must prevent restarting of the timer, Ifwe have no this synchronization, there is a small probability that thecancellation will not be successful.And syzbot report the fellowing crash:==================================================================BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605Write at addr f9ff000024df6058 by task syz-fuzzer/2256Pointer tag: [f9], memory tag: [fe]CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-ge01d50cbd6ee #0Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519To fix it, we can introduce a new active flags to make sure the timer willnot restart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sgThe calling convention for pre_slave_sg is to return NULL on error andprovide an error log to the system. Qcom-adm instead provide errorpointer when an error occur. This indirectly cause kernel panic forexample for the nandc driver that checks only if the pointer returned bydevice_prep_slave_sg is not NULL. Returning an error pointer makes nandcthink the device_prep_slave_sg function correctly completed and makesthe kernel panics later in the code.While nandc is the one that makes the kernel crash, it was pointed outthat the real problem is qcom-adm not following calling convention forthat function.To fix this, drop returning error pointer and return NULL with an errorlog.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cacheinfo: Fix shared_cpu_map to handle shared caches at different levelsThe cacheinfo sets up the shared_cpu_map by checking whether the cacheswith the same index are shared between CPUs. However, this will triggerslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.Another problem is the mismatched shared_cpu_map when the shared cache doesnot have the same index between CPUs.CPU0 I D L3index 0 1 2 x ^ ^ ^ ^index 0 1 2 3CPU1 I D L2 L3This patch checks each cache is shared with all caches on other CPUs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()The finalization of nilfs_segctor_thread() can race withnilfs_segctor_kill_thread() which terminates that thread, potentiallycausing a use-after-free BUG as KASAN detected.At the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" memberof "struct nilfs_sc_info" to indicate the thread has finished, and thennotifies nilfs_segctor_kill_thread() of this using waitqueue"sc_wait_task" on the struct nilfs_sc_info.However, here, immediately after the NULL assignment to "sc_task", it ispossible that nilfs_segctor_kill_thread() will detect it and return tocontinue the deallocation, freeing the nilfs_sc_info structure before thethread does the notification.This fixes the issue by protecting the NULL assignment to "sc_task" andits notification, with spinlock "sc_state_lock" of the structnilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check tosee if "sc_task" is NULL with "sc_state_lock" locked, this can eliminatethe race.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: lpass: Fix for KASAN use_after_free out of boundsWhen we run syzkaller we get below Out of Bounds error."KASAN: slab-out-of-bounds Read in regcache_flat_read"Below is the backtrace of the issue:BUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G WHardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)Call trace:dump_backtrace+0x0/0x4ecshow_stack+0x34/0x50dump_stack_lvl+0xdc/0x11cprint_address_description+0x30/0x2d8kasan_report+0x178/0x1e4__asan_report_load4_noabort+0x44/0x50regcache_flat_read+0x10c/0x110regcache_read+0xf8/0x5a0_regmap_read+0x45c/0x86c_regmap_update_bits+0x128/0x290regmap_update_bits_base+0xc0/0x15csnd_soc_component_update_bits+0xa8/0x22csnd_soc_component_write_field+0x68/0xd4tx_macro_put_dec_enum+0x1d0/0x268snd_ctl_elem_write+0x288/0x474By Error checking and checking valid values issue gets rectifies.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()Fix a stack-out-of-bounds write that occurs in a WMI response callbackfunction that is called after a timeout occurs in ath9k_wmi_cmd().The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer thatcould no longer be valid when a timeout occurs. Set wmi->last_seq_id to0 when a timeout occurred.Found by a modified version of syzkaller.BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rxWrite of size 4Call Trace: memcpy ath9k_wmi_ctrl_rx ath9k_htc_rx_msg ath9k_hif_usb_reg_in_cb __usb_hcd_giveback_urb usb_hcd_giveback_urb dummy_timer call_timer_fn run_timer_softirq __do_softirq irq_exit_rcu sysvec_apic_timer_interrupt
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in tcp_write_timer_handler().With Eric's ref tracker, syzbot finally found a repro foruse-after-free in tcp_write_timer_handler() by kernel TCPsockets. [0]If SMC creates a kernel socket in __smc_create(), the kernelsocket is supposed to be freed in smc_clcsock_release() bycalling sock_release() when we close() the parent SMC socket.However, at the end of smc_clcsock_release(), the kernelsocket's sk_state might not be TCP_CLOSE. This means thatwe have not called inet_csk_destroy_sock() in __tcp_close()and have not stopped the TCP timers.The kernel socket's TCP timers can be fired later, so weneed to hold a refcnt for net as we do for MPTCP subflowsin mptcp_subflow_create_socket().[0]:leaked reference. sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108) inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244) __sock_create (net/socket.c:1546) smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284) __sock_create (net/socket.c:1546) __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661) __x64_sys_socket (net/socket.c:1672) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)==================================================================BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) kasan_report (mm/kasan/report.c:538) tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022) run_timer_softirq (kernel/time/timer.c:2037) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572) __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650) irq_exit_rcu (kernel/softirq.c:664) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Fix use-after-free in __gtp_encap_destroy().syzkaller reported use-after-free in __gtp_encap_destroy(). [0]It shows the same process freed sk and touched it illegally.Commit e198987e7dd7 ("gtp: fix suspicious RCU usage") added lock_sock()and release_sock() in __gtp_encap_destroy() to protect sk->sk_user_data,but release_sock() is called after sock_put() releases the last refcnt.[0]:BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]BUG: KASAN: slab-use-after-free in atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]BUG: KASAN: slab-use-after-free in queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]BUG: KASAN: slab-use-after-free in do_raw_spin_lock include/linux/spinlock.h:186 [inline]BUG: KASAN: slab-use-after-free in __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]BUG: KASAN: slab-use-after-free in _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178Write of size 4 at addr ffff88800dbef398 by task syz-executor.2/2401CPU: 1 PID: 2401 Comm: syz-executor.2 Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:351 [inline] print_report+0xcc/0x620 mm/kasan/report.c:462 kasan_report+0xb2/0xe0 mm/kasan/report.c:572 check_region_inline mm/kasan/generic.c:181 [inline] kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:187 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline] queued_spin_lock include/asm-generic/qspinlock.h:111 [inline] do_raw_spin_lock include/linux/spinlock.h:186 [inline] __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline] _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:355 [inline] release_sock+0x1f/0x1a0 net/core/sock.c:3526 gtp_encap_disable_sock drivers/net/gtp.c:651 [inline] gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664 gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728 unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841 rtnl_delete_link net/core/rtnetlink.c:3216 [inline] rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268 rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423 netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x1b7/0x200 net/socket.c:747 ____sys_sendmsg+0x75a/0x990 net/socket.c:2493 ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547 __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7f1168b1fe5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007f1167edccc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f1168b1fe5dRDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007f1168b80530 R15: 0000000000000000 Allocated by task 1483: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix ordering of qlen adjustmentChanges to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen_before_ a call to said function because otherwise it may fail to notifyparent qdiscs when the child is about to become empty.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: prevent use-after-free due to open_cached_dir error pathsIf open_cached_dir() encounters an error parsing the lease from theserver, the error handling may race with receiving a lease break,resulting in open_cached_dir() freeing the cfid while the queued work ispending.Update open_cached_dir() to drop refs rather than directly freeing thecfid.Have cached_dir_lease_break(), cfids_laundromat_worker(), andinvalidate_all_cached_dirs() clear has_lease immediately while stillholding cfids->cfid_list_lock, and then use this to also simplify thereference counting in cfids_laundromat_worker() andinvalidate_all_cached_dirs().Fixes this KASAN splat (which manually injects an error and lease breakin open_cached_dir()):==================================================================BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Workqueue: cifsiod smb2_cached_lease_breakCall Trace: dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eLast potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free of signing keyCustomers have reported use-after-free in @ses->auth_key.response withSMB2.1 + sign mounts which occurs due to following race:task A task Bcifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF*Fix this by ensuring that we have a valid @ses->auth_key.response bychecking whether @ses->ses_status is SES_GOOD or SES_EXITING with@ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAFin smb2_reconnect_server()"), we made sure to call ->logoff() onlywhen @ses was known to be good (e.g. valid ->auth_key.response), soit's safe to access signing key when @ses->ses_status == SES_EXITING.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: array-index-out-of-bounds fix in dtReadFirstThe value of stbl can be sometimes out of bounds dueto a bad filesystem. Added a check with appopriate returnof error code in that case.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix use after free on unloadSystem crash is observed with stack trace warning of use afterfree. There are 2 signals to tell dpc_thread to terminate (UNLOADINGflag and kthread_stop).On setting the UNLOADING flag when dpc_thread happens to run at the timeand sees the flag, this causes dpc_thread to exit and clean upitself. When kthread_stop is called for final cleanup, this causes useafter free.Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stopas the main signal to exit dpc_thread.[596663.812935] kernel BUG at mm/slub.c:294![596663.812950] invalid opcode: 0000 [#1] SMP PTI[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012[596663.812974] RIP: 0010:__slab_free+0x17d/0x360...[596663.813008] Call Trace:[596663.813022] ? __dentry_kill+0x121/0x170[596663.813030] ? _cond_resched+0x15/0x30[596663.813034] ? _cond_resched+0x15/0x30[596663.813039] ? wait_for_completion+0x35/0x190[596663.813048] ? try_to_wake_up+0x63/0x540[596663.813055] free_task+0x5a/0x60[596663.813061] kthread_stop+0xf3/0x100[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Fix slab-use-after-free read in sg_release()Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30kernel/locking/lockdep.c:5838__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) iscalled before releasing the open_rel_lock mutex. The kref_put() call maydecrement the reference count of sfp to zero, triggering its cleanupthrough sg_remove_sfp(). This cleanup includes scheduling deferred workvia sg_remove_sfp_usercontext(), which ultimately frees sfp.After kref_put(), sg_release() continues to unlock open_rel_lock and mayreference sfp or sdp. If sfp has already been freed, this results in aslab-use-after-free error.Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking theopen_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release().The fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures propersequencing of resource cleanup and mutex operations, eliminating therisk of use-after-free errors in sg_release().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: hi3110_can_ist(): fix potential use-after-freeThe commit a22bd630cfff ("can: hi311x: do not report txerr and rxerrduring bus-off") removed the reporting of rxerr and txerr even in caseof correct operation (i. e. not bus-off).The error count information added to the CAN frame after netif_rx() isa potential use after free, since there is no guarantee that the skbis in the same state. It might be freed or reused.Fix the issue by postponing the netif_rx() call in case of txerr andrxerr reporting.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix race between element replace and close()Element replace (with a socket different from the one stored) may racewith socket's close() link popping & unlinking. __sock_map_delete()unconditionally unrefs the (wrong) element:// set map[0] = s0map_update_elem(map, 0, s0)// drop fd of s0close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)Then close(map) enqueues bpf_map_free_deferred, which finally callssock_map_free(). This results in some refcount_t warnings along witha KASAN splat [1].Fix __sock_map_delete(), do not allow sock_map_unref() on elements thatmay have been replaced.[1]:BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014Workqueue: events_unbound bpf_map_free_deferredCall Trace: dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30The bu---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when COWing tree bock and tracing is enabledWhen a COWing a tree block, at btrfs_cow_block(), and we have thetracepoint trace_btrfs_cow_block() enabled and preemption is also enabled(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extentbuffer while inside the tracepoint code. This is because in some pathsthat call btrfs_cow_block(), such as btrfs_search_slot(), we are holdingthe last reference on the extent buffer @buf so btrfs_force_cow_block()drops the last reference on the @buf extent buffer when it callsfree_extent_buffer_stale(buf), which schedules the release of the extentbuffer with RCU. This means that if we are on a kernel with preemption,the current task may be preempted before calling trace_btrfs_cow_block()and the extent buffer already released by the time trace_btrfs_cow_block()is called, resulting in a use-after-free.Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() tobtrfs_force_cow_block() before the COWed extent buffer is freed.This also has a side effect of invoking the tracepoint in the tree defragcode, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() iscalled there, but this is fine and it was actually missing there.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: Fix use-after-free in page_pool_recycle_in_ringsyzbot reported a uaf in page_pool_recycle_in_ring:BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]root cause is:page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free spin_unlock(&r->producer_lock); //pool->ring uaf read recycle_stat_inc(pool, ring);page_pool can be free while page pool recycle the last page in ring.Add producer-lock barrier to page_pool_release to prevent the pagepool from being free before all pages have been recycled.recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is notenabled, which will trigger Wempty-body build warning. Add definitionfor pool stat macro to fix warning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix the 'para' buffer size to avoid reading out of boundsSet the size to 6 instead of 2, since 'para' array is passed to'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads5 bytes:void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data){ ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));Detected using the static analysis tool - Svace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: ensure the received length does not exceed allocated sizeIn xdp_linearize_page, when reading the following buffers from the ring,we forget to check the received length with the true allocate size. Thiscan lead to an out-of-bound read. This commit adds that missing check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Prevent use-after-free during requeue-PIsyzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL);In this scenario futex_wait_requeue_pi() is able to leave without usingfutex_q::lock_ptr for synchronization.This can be prevented by reading futex_q::task before updating thefutex_q::requeue_state. A reference on the task_struct is not neededbecause requeue_pi_wake_futex() is invoked with a spinlock_t held whichimplies a RCU read section.Even if T1 terminates immediately after, the task_struct will remain validduring T2's wake_up_state(). A READ_ONCE on futex_q::task beforefutex_requeue_pi_complete() is enough because it ensures that the variableis read before the state is updated.Read futex_q::task before updating the requeue state, use it for thefollowing wakeup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race condition in mptcp_schedule_work()syzbot reported use-after-free in mptcp_schedule_work() [1]Issue here is that mptcp_schedule_work() schedules a work,then gets a refcount on sk->sk_refcnt if the work was scheduled.This refcount will be released by mptcp_worker().[A] if (schedule_work(...)) {[B] sock_hold(sk); return true; }Problem is that mptcp_worker() can run immediately and complete before [B]We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk);[1]refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_mon_reinit_self().syzbot reported use-after-free of tipc_net(net)->monitors[]in tipc_mon_reinit_self(). [0]The array is protected by RTNL, but tipc_mon_reinit_self()iterates over it without RTNL.tipc_mon_reinit_self() is called from tipc_net_finalize(),which is always under RTNL except for tipc_net_finalize_work().Let's hold RTNL in tipc_net_finalize_work().[0]:BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Workqueue: events tipc_net_finalize_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_conn_freeBUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410net/bluetooth/sco.c:107Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci13 hci_cmd_sync_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: avoid scheduling association deletion twiceWhen forcefully shutting down a port via the configfs interface,nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() andthen nvmet_disable_port(). Both functions will eventually schedule allremaining associations for deletion.The current implementation checks whether an association is about to beremoved, but only after the work item has already been scheduled. As aresult, it is possible for the first scheduled work item to free allresources, and then for the same work item to be scheduled again fordeletion.Because the association list is an RCU list, it is not possible to takea lock and remove the list entry directly, so it cannot be looked upagain. Instead, a flag (terminating) must be used to determine whetherthe association is already in the process of being deleted.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix race in syncpt alloc/freeFix race condition between host1x_syncpt_alloc()and host1x_syncpt_put() by using kref_put_mutex()instead of kref_put() + manual mutex locking.This ensures no thread can acquire thesyncpt_mutex after the refcount drops to zerobut before syncpt_release acquires it.This prevents races where syncpoints couldbe allocated while still being cleaned upfrom a previous release.Remove explicit mutex locking in syncpt_releaseas kref_put_mutex() handles this atomically.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: fsl-usb: Fix use-after-free in delayed work during device removalThe delayed work item otg_event is initialized in fsl_otg_conf() andscheduled under two conditions:1. When a host controller binds to the OTG controller.2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via fsl_otg_remove():the fsl_otg instance may be freed while the delayed work is still pendingor executing. This leads to use-after-free when the work functionfsl_otg_event() accesses the already freed memory.The problematic scenario:(detach thread) | (delayed work)fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove()before deallocating the fsl_otg structure. This ensures the delayed workis properly canceled and completes execution prior to memory deallocation.This bug was identified through static analysis.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driverAfter unbinding the driver, another kthread `cros_ec_console_log_work`is still accessing the device, resulting an UAF and crash.The driver doesn't unregister the EC device in .remove() which shouldshutdown sub-devices synchronously. Fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu: disable SVA when CONFIG_X86 is setPatch series "Fix stale IOTLB entries for kernel address space", v7.This proposes a fix for a security vulnerability related to IOMMU SharedVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernelpage table entries. When a kernel page table page is freed andreallocated for another purpose, the IOMMU might still hold stale,incorrect entries. This can be exploited to cause a use-after-free orwrite-after-free condition, potentially leading to privilege escalation ordata corruption.This solution introduces a deferred freeing mechanism for kernel pagetable pages, which provides a safe window to notify the IOMMU toinvalidate its caches before the page is reused.This patch (of 8):In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardwareshares and walks the CPU's page tables. The x86 architecture maps thekernel's virtual address space into the upper portion of every process'spage table. Consequently, in an SVA context, the IOMMU hardware can walkand cache kernel page table entries.The Linux kernel currently lacks a notification mechanism for kernel pagetable changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual addressmappings. This can cause the IOMMU's internal caches to retain staleentries for kernel VA.Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise whenkernel page table pages are freed and later reallocated. The IOMMU couldmisinterpret the new data as valid page table entries. The IOMMU mightthen walk into attacker-controlled memory, leading to arbitrary physicalmemory DMA access or privilege escalation. This is also aWrite-After-Free issue, as the IOMMU will potentially continue to writeAccessed and Dirty bits to the freed memory while attempting to walk thestale page tables.Currently, SVA contexts are unprivileged and cannot access kernelmappings. However, the IOMMU will still walk kernel-only page tables allthe way down to the leaf entries, where it realizes the mapping is for thekernel and errors out. This means the IOMMU still caches theseintermediate page table entries, making the described vulnerability a realconcern.Disable SVA on x86 architecture until the IOMMU can receive notificationto flush the paging cache before freeing the CPU kernel page table pages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add VLAN id validation before usingCurrently, the VLAN id may be used without validation whenreceive a VLAN configuration mailbox from VF. The length ofvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may causeout-of-bounds memory access once the VLAN id is bigger thanor equal to VLAN_N_VID.Therefore, VLAN id needs to be checked to ensure it is withinthe range of VLAN_N_VID.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erspan: Initialize options_len before referencing options.The struct ip_tunnel_info has a flexible array member namedoptions that is protected by a counted_by(options_len)attribute.The compiler will use this information to enforce runtime boundschecking deployed by FORTIFY_SOURCE string helpers.As laid out in the GCC documentation, the counter must beinitialized before the first reference to the flexible arraymember.After scanning through the files that use struct ip_tunnel_infoand also refer to options or options_len, it appears the normalcase is to use the ip_tunnel_info_opts_set() helper.Said helper would initialize options_len properly before copyingdata into options, however in the GRE ERSPAN code a partialupdate is done, preventing the use of the helper function.Before this change the handling of ERSPAN traffic in GRE tunnelswould cause a kernel panic when the kernel is compiled withGCC 15+ and having FORTIFY_SOURCE configured:memcpy: detected buffer overflow: 4 byte write of buffer size 0Call Trace: __fortify_panic+0xd/0xf erspan_rcv.cold+0x68/0x83 ? ip_route_input_slow+0x816/0x9d0 gre_rcv+0x1b2/0x1c0 gre_rcv+0x8e/0x100 ? raw_v4_input+0x2a0/0x2b0 ip_protocol_deliver_rcu+0x1ea/0x210 ip_local_deliver_finish+0x86/0x110 ip_local_deliver+0x65/0x110 ? ip_rcv_finish_core+0xd6/0x360 ip_rcv+0x186/0x1a0Reported-at: https://launchpad.net/bugs/2129580
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libsodium23 > 0-0 (version in image is 1.0.18-150000.4.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: storage: sddr55: Reject out-of-bound new_pbaDiscovered by Atuin - Automated Vulnerability Discovery Engine.new_pba comes from the status packet returned after each write.A bogus device could report values beyond the block count derivedfrom info->capacity, letting the driver walk off the end ofpba_to_lba[] and corrupt heap memory.Reject PBAs that exceed the computed block count and fail thetransfer so we avoid touching out-of-range mapping entries.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).
-
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.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).
-
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.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).
-
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.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).
-
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.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).
-
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.5 (version in image is 15.5-150500.61.4.1).
- libldap-2_4-2 > 0-0 (version in image is 2.4.46-150200.14.17.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libpng16-16 > 0-0 (version in image is 1.6.34-3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZEROPrecision markers need to be propagated whenever we have an ARG_CONST_*style argument, as the verifier cannot consider imprecise scalars to beequivalent for the purposes of states_equal check when such argumentsrefine the return value (in this case, set mem_size for PTR_TO_MEM). Theresultant mem_size for the R0 is derived from the constant value, and ifthe verifier incorrectly prunes states considering them equivalent wheresuch arguments exist (by seeing that both registers have reg->precise asfalse in regsafe), we can end up with invalid programs passing theverifier which can do access beyond what should have been the correctmem_size in that explored state.To show a concrete example of the problem:0000000000000000
: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -10000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit00000000000000b8 : 23: w0 = 0 24: exitFor the first case, the single line execution's exploration will prunethe search at insn 14 for the branch insn 9's second leg as it will beverified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 willalways be 0 so at runtime we don't get error for being greater thanUINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe justsees reg->precise as false for both r2 registers in both states, henceconsiders them equal for purposes of states_equal.If we propagated precise markers using the backtracking support, wewould use the precise marking to then ensure that old r2 (UINT_MAX) waswithin the new r2 (1) and this would never be true, so the verificationwould rightfully fail.The end result is that the out of bounds access at instruction 19 wouldbe permitted without this fix.Note that reg->precise is always set to true when user does not haveCAP_BPF (or when subprog count is greater than 1 (i.e. use of any staticor global functions)), hence this is only a problem when precision marksneed to be explicitly propagated (i.e. privileged users with CAP_BPF).A simplified test case has been included in the next patch to preventfuture regressions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: fix use-after-free on probe deferralThe bridge counter was never reset when tearing down the DRM device sothat stale pointers to deallocated structures would be accessed on thenext tear down (e.g. after a second late bind deferral).Given enough bridges and a few probe deferrals this could currently alsolead to data beyond the bridge array being corrupted.Patchwork: https://patchwork.freedesktop.org/patch/502665/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: do not free live elementPablo reports a crash with large batches of elements with aback-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.Looking at the remove function there is a chance that we will drop arule that maps to a non-deactivated element.Removal happens in two steps, first we do a lookup for key k and return theto-be-removed element and mark it as inactive in the next generation.Then, in a second step, the element gets removed from the set/map.The _remove function does not work correctly if we have more than oneelement that share the same key.This can happen if we insert an element into a set when the set alreadyholds an element with same key, but the element mapping to the existingkey has timed out or is not active in the next generation.In such case its possible that removal will unmap the wrong element.If this happens, we will leak the non-deactivated element, it becomesunreachable.The element that got deactivated (and will be freed later) willremain reachable in the set data structure, this can result ina crash when such an element is retrieved during lookup (stalepointer).Add a check that the fully matching key does in fact map to the elementthat we have marked as inactive in the deactivation step.If not, we need to continue searching.Add a bug/warn trap at the end of the function as well, the removefunction must not ever be called with an invisible/unreachable/non-existentelement.v2: avoid uneeded temporary variable (Stefano)
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: use timestamp to check for set element timeoutAdd a timestamp field at the beginning of the transaction, store itin the nftables per-netns area.Update set backend .insert, .deactivate and sync gc path to use thetimestamp, this avoids that an element expires while control planetransaction is still unfinished..lookup and .update, which are used from packet path, still use thecurrent time to check if the element has expired. And .get path and dumpalso since this runs lockless under rcu read size lock. Then, there isasync gc which also needs to check the current time since it runsasynchronously from a workqueue.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix overloading of MEM_UNINIT's meaningLonial reported an issue in the BPF verifier where check_mem_size_reg()has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL;This means that writes are not checked when the register containing thesize of the passed buffer has not a fixed size. Through this bug, a BPFprogram can write to a map which is marked as read-only, for example,.rodata global maps.The problem is that MEM_UNINIT's initial meaning that "the passed bufferto the BPF helper does not need to be initialized" which was added backin commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type")got overloaded over time with "the passed buffer is being written to".The problem however is that checks such as the above which were added latervia 06c1c049721a ("bpf: allow helpers access to variable memory") set metato NULL in order force the user to always initialize the passed buffer tothe helper. Due to the current double meaning of MEM_UNINIT, this bypassesverifier write checks to the memory (not boundary checks though) and onlyassumes the latter memory is read instead.Fix this by reverting MEM_UNINIT back to its original meaning, and havingMEM_WRITE as an annotation to BPF helpers in order to then trigger theBPF verifier checks for writing to memory.Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}we can access fn->arg_type[arg - 1] since it must contain a precedingARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removedaltogether since we do check both BPF_READ and BPF_WRITE. Same for theequivalent check_kfunc_mem_size_reg().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix usage slab after free[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020[ +0.000016] Call Trace:[ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0[ +0.000017] print_report+0xce/0x5f0[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] ? srso_return_thunk+0x5/0x5f[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] kasan_report+0xbe/0x110[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000023] __asan_report_load8_noabort+0x14/0x30[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? enable_work+0x124/0x220[ +0.000015] ? __pfx_enable_work+0x10/0x10[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? free_large_kmalloc+0x85/0xf0[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched][ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu][ +0.000735] ? __kasan_check_read+0x11/0x20[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu][ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu][ +0.000679] ? mutex_unlock+0x80/0xe0[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu][ +0.000662] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? mutex_unlock+0x80/0xe0[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu][ +0.000663] drm_minor_release+0xc9/0x140 [drm][ +0.000081] drm_release+0x1fd/0x390 [drm][ +0.000082] __fput+0x36c/0xad0[ +0.000018] __fput_sync+0x3c/0x50[ +0.000014] __x64_sys_close+0x7d/0xe0[ +0.000014] x64_sys_call+0x1bc6/0x2680[ +0.000014] do_syscall_64+0x70/0x130[ +0.000014] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190[ +0.000015] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit+0x43/0x50[ +0.000012] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? exc_page_fault+0x7c/0x110[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ +0.000014] RIP: 0033:0x7ffff7b14f67[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040[ +0.000020] [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:[ +0.000014] kasan_save_stack+0x28/0x60[ +0.000008] kasan_save_track+0x18/0x70[ +0.000007] kasan_save_alloc_info+0x38/0x60[ +0.000007] __kasan_kmalloc+0xc1/0xd0[ +0.000007] kmalloc_trace_noprof+0x180/0x380[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched][ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu][ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu][ +0.000662] amdgpu_pci_p---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/igen6: Avoid segmentation fault on module unloadThe segmentation fault happens because:During modprobe:1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc]During rmmod:1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info)2. In igen6_remove(), it will kfree(igen6_pvt);Fix this issue by setting mci->pvt_info to NULL to avoid the doublekfree.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries/vas: Add close() callback in vas_vm_ops structThe mapping VMA address is saved in VAS window struct when thepaste address is mapped. This VMA address is used during migrationto unmap the paste address if the window is active. The pasteaddress mapping will be removed when the window is closed or withthe munmap(). But the VMA address in the VAS window is not updatedwith munmap() which is causing invalid access during migration.The KASAN report shows:[16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8[16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928[16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G B 6.11.0-rc5-nxgzip #2[16386.255128] Tainted: [B]=BAD_PAGE[16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries[16386.255181] Call Trace:[16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable)[16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764[16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8[16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0[16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8[16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc[16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4...[16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s:[16386.256149] kasan_save_stack+0x34/0x68[16386.256163] kasan_save_track+0x34/0x80[16386.256175] kasan_save_alloc_info+0x58/0x74[16386.256196] __kasan_slab_alloc+0xb8/0xdc[16386.256209] kmem_cache_alloc_noprof+0x200/0x3d0[16386.256225] vm_area_alloc+0x44/0x150[16386.256245] mmap_region+0x214/0x10c4[16386.256265] do_mmap+0x5fc/0x750[16386.256277] vm_mmap_pgoff+0x14c/0x24c[16386.256292] ksys_mmap_pgoff+0x20c/0x348[16386.256303] sys_mmap+0xd0/0x160...[16386.256350] Freed by task 0 on cpu 31 at 16386.204848s:[16386.256363] kasan_save_stack+0x34/0x68[16386.256374] kasan_save_track+0x34/0x80[16386.256384] kasan_save_free_info+0x64/0x10c[16386.256396] __kasan_slab_free+0x120/0x204[16386.256415] kmem_cache_free+0x128/0x450[16386.256428] vm_area_free_rcu_cb+0xa8/0xd8[16386.256441] rcu_do_batch+0x2c8/0xcf0[16386.256458] rcu_core+0x378/0x3c4[16386.256473] handle_softirqs+0x20c/0x60c[16386.256495] do_softirq_own_stack+0x6c/0x88[16386.256509] do_softirq_own_stack+0x58/0x88[16386.256521] __irq_exit_rcu+0x1a4/0x20c[16386.256533] irq_exit+0x20/0x38[16386.256544] interrupt_async_exit_prepare.constprop.0+0x18/0x2c...[16386.256717] Last potentially related work creation:[16386.256729] kasan_save_stack+0x34/0x68[16386.256741] __kasan_record_aux_stack+0xcc/0x12c[16386.256753] __call_rcu_common.constprop.0+0x94/0xd04[16386.256766] vm_area_free+0x28/0x3c[16386.256778] remove_vma+0xf4/0x114[16386.256797] do_vmi_align_munmap.constprop.0+0x684/0x870[16386.256811] __vm_munmap+0xe0/0x1f8[16386.256821] sys_munmap+0x54/0x6c[16386.256830] system_call_exception+0x1a0/0x4a0[16386.256841] system_call_vectored_common+0x15c/0x2ec[16386.256868] The buggy address belongs to the object at c00000014a819670 which belongs to the cache vm_area_struct of size 168[16386.256887] The buggy address is located 0 bytes inside of freed 168-byte region [c00000014a819670, c00000014a819718)[16386.256915] The buggy address belongs to the physical page:[16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81[16386.256950] memcg:c0000000ba430001[16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff)[16386.256975] page_type: 0xfdffffff(slab)[16386---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Remove the direct link to net_deviceThe similar patch in siw is in the link:https://git.kernel.org/rdma/rdma/c/16b87037b48889This problem also occurred in RXE. The following analyze this problem.In the following Call Traces:"BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 09/13/2024Workqueue: infiniband ib_cache_event_taskCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 "1). In the link [1]," infiniband syz2: set down"This means that on 839.350575, the event ib_cache_event_task was sent andiqueued in ib_wq.2). In the link [1]," team0 (unregistering): Port device team_slave_0 removed"It indicates that before 843.251853, the net device should be freed.3). In the link [1]," BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0"This means that on 850.559070, this slab-use-after-free problem occurred.In all, on 839.350575, the event ib_cache_event_task was sent and queuedin ib_wq,before 843.251853, the net device veth was freed.on 850.559070, this event was executed, and the mentioned freed net devicewas called. Thus, the above call trace occurred.[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Remove direct link to net_deviceDo not manage a per device direct link to net_device. Relyon associated ib_devices net_device management, not doublingthe effort locally. A badly managed local link to net_devicewas causing a 'KASAN: slab-use-after-free' exception duringsiw_query_port() call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix use-after free in init error and remove pathsdevm_blk_crypto_profile_init() registers a cleanup handler to run whenthe associated (platform-) device is being released. For UFS, thecrypto private data and pointers are stored as part of the ufs_hba'sdata structure 'struct ufs_hba::crypto_profile'. This structure isallocated as part of the underlying ufshcd and therefore Scsi_hostallocation.During driver release or during error handling in ufshcd_pltfrm_init(),this structure is released as part of ufshcd_dealloc_host() before the(platform-) device associated with the crypto call above is released.Once this device is released, the crypto cleanup code will run, usingthe just-released 'struct ufs_hba::crypto_profile'. This causes ause-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-deviceand during error handling of ufshcd_pltfrm_init() or during driverremoval: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handlerTo fix this use-after free, change ufshcd_alloc_host() to register adevres action to automatically cleanup the underlying SCSI device onufshcd destruction, without requiring explicit calls toufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: pktgen: fix access outside of user given buffer in pktgen_thread_write()Honour the user given buffer size for the strn_len() calls (otherwisestrn_len() will access memory outside of the user given buffer).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix UAF when lookup kallsym after ftrace disabledThe following issue happens with a buggy module:BUG: unable to handle page fault for address: ffffffffc05d0218PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0Oops: Oops: 0000 [#1] SMP KASAN PTITainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSRIP: 0010:sized_strscpy+0x81/0x2f0RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2dRBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeffFS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue may happen as follows:(1) Add kprobe tracepoint;(2) insmod test.ko;(3) Module triggers ftrace disabled;(4) rmmod test.ko;(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;ftrace_mod_get_kallsym()...strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);...The problem is when a module triggers an issue with ftrace andsets ftrace_disable. The ftrace_disable is set when an anomaly isdiscovered and to prevent any more damage, ftrace stops all textmodification. The issue that happened was that the ftrace_disable stopsmore than just the text modification.When a module is loaded, its init functions can also be traced. Becausekallsyms deletes the init functions after a module has loaded, ftracesaves them when the module is loaded and function tracing is enabled. Thisallows the output of the function trace to show the init function namesinstead of just their raw memory addresses.When a module is removed, ftrace_release_mod() is called, and ifftrace_disable is set, it just returns without doing anything more. Theproblem here is that it leaves the mod_list still around and if kallsymsis called, it will call into this code and access the module memory thathas already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);Where the "mod" no longer exists and triggers a UAF bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-stripe: fix a possible integer overflowThere's a possible integer overflow in stripe_io_hints if we have toolarge chunk size. Test if the overflow happened, and if it did, don't setlimits->io_min and limits->io_opt;
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_router: Fix neighbour use-after-freeWe sometimes observe use-after-free when dereferencing a neighbour [1].The problem seems to be that the driver stores a pointer to theneighbour, but without holding a reference on it. A reference is onlytaken when the neighbour is used by a nexthop.Fix by simplifying the reference counting scheme. Always take areference when storing a neighbour pointer in a neighbour entry. Avoidtaking a referencing when the neighbour is used by a nexthop as theneighbour entry associated with the nexthop already holds a reference.Tested by running the test that uncovered the problem over 300 times.Without this patch the problem was reproduced after a handful ofiterations.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310Read of size 8 at addr ffff88817f8e3420 by task ip/3929CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[...]Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in l2tp_ip6_sendmsgWhen len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will beoverflow. To fix, we can follow what udpv6 does and subtract thetranshdrlen from the max.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in __ip6_append_dataResurrect ubsan overflow checks and ubsan report this warning,fix it by change the variable [length] type to size_t.UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:192147479552 + 8567 cannot be represented in type 'int'CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170Changes since v1:-Change the variable [length] type to unsigned, as Eric Dumazet suggested.Changes since v2:-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.Changes since v3:-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, asJakub Kicinski suggested.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inodeThere are many places that will get unhappy (and crash) when ext4_iget()returns a bad inode. However, if iget the boot loader inode, allows a badinode to be returned, because the inode may not be initialized. Thismechanism can be used to bypass some checks and cause panic. To solve thisproblem, we add a special iget flag EXT4_IGET_BAD. Only with this flagwe'd be returning bad inode from ext4_iget(), otherwise we always returnthe error code if the inode is bad inode.(suggested by Jan Kara)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix OOB Read in __hfs_brec_findSyzbot reported a OOB read bug:==================================================================BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190fs/hfs/string.c:84Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted6.1.0-rc6-syzkaller-00308-g644e9524388a #0Workqueue: writeback wb_workfn (flush-7:0)Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75 hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138 hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462 write_inode fs/fs-writeback.c:1440 [inline]If the input inode of hfs_write_inode() is incorrect:struct inode struct hfs_inode_info struct hfs_cat_key struct hfs_name u8 len # len is greater than HFS_NAMELEN(31) which is themaximum length of an HFS filenameOOB read occurred:hfs_write_inode() hfs_brec_find() __hfs_brec_find() hfs_cat_keycmp() hfs_strcmp() # OOB read occurred due to len is too largeFix this by adding a Check on len in hfs_write_inode() before callinghfs_brec_find().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid use-after-free for cached IPU bioxfstest generic/019 reports a bug:kernel BUG at mm/filemap.c:1619!RIP: 0010:folio_end_writeback+0x8a/0x90Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()in f2fs_write_single_data_page() tries to flush IPU bio in cache, howeverf2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,result in submitting random cached bio which belong to other IO context,then it will cause use-after-free issue, fix it by adding additionalvalidity check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: fix uninit-value use in udf_get_fileshortadCheck for overflow when computing alen in udf_current_aext to mitigatelater uninit-value use in udf_get_fileshortad KMSAN bug[1].After applying the patch reproducer did not trigger any issue[2].[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds write in trie_get_next_key()trie_get_next_key() allocates a node stack with size trie->max_prefixlen,while it writes (trie->max_prefixlen + 1) nodes to the stack when it hasfull paths from the root to leaves. For example, consider a trie withmax_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with.prefixlen = 8 make 9 nodes be written on the node stack with size 8.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out of bounds reads when finding clock sourcesThe current USB-audio driver code doesn't check bLength of eachdescriptor at traversing for clock descriptors. That is, when adevice provides a bogus descriptor with a shorter bLength, the drivermight hit out-of-bounds reads.For addressing it, this patch adds sanity checks to the validatorfunctions for the clock descriptor traversal. When the descriptorlength is shorter than expected, it's skipped in the loop.For the clock source and clock multiplier descriptors, we can justcheck bLength against the sizeof() of each descriptor type.OTOH, the clock selector descriptor of UAC2 and UAC3 has an arrayof bNrInPins elements and two more fields at its tail, hence thosehave to be checked in addition to the sizeof() check.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat/qat_4xxx - fix off by one in uof_get_name()The fw_objs[] array has "num_objs" elements so the > needs to be >= toprevent an out of bounds read.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check for overflows in io_pin_pagesWARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can begarbage. Don't just add size to it as it can overflow.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: fix potential array underflow in ucsi_ccg_sync_control()The "command" variable can be controlled by the user via debugfs. Theworry is that if con_index is zero then "&uc->ucsi->connector[con_index- 1]" would be an array underflow.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: release svc_expkey/svc_export with rcu_workThe last reference for `cache_head` can be reduced to zero in `c_show`and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,`svc_export_put` and `expkey_put` will be invoked, leading to twoissues:1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Fix these issues by using `rcu_work` to help release`svc_expkey`/`svc_export`. This approach allows for an asynchronouscontext to invoke `path_put` and also facilitates the freeing of`uuid/exp/key` after an RCU grace period.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctlFix an issue detected by syzbot with KASAN:BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/core.c:416 [inline]BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0drivers/acpi/nfit/core.c:459The issue occurs in cmd_to_func when the call_pkg->nd_reserved2array is accessed without verifying that call_pkg points to a bufferthat is appropriately sized as a struct nd_cmd_pkg. This can leadto out-of-bounds access and undefined behavior if the buffer does nothave sufficient space.To address this, a check was added in acpi_nfit_ctl() to ensure thatbuf is not NULL and that buf_len is less than sizeof(*call_pkg)before accessing it. This ensures safe access to the members ofcall_pkg, including the nd_reserved2 array.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Prevent integer overflow issueIn the expression "cmd.wqe_size * cmd.wr_count", both variables are u32values that come from the user so the multiplication can lead to integerwrapping. Then we pass the result to uverbs_request_next_ptr() which alsocould potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"multiplication can also overflow on 32bit systems although it's fine on64bit systems.This patch does two things. First, I've re-arranged the condition inuverbs_request_next_ptr() so that the use controlled variable "len" is onone side of the comparison by itself without any math. Then I've modifiedall the callers to use size_mul() for the multiplications.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAXShifting 1 << 31 on a 32-bit int causes signed integer overflow, whichleads to undefined behavior. To prevent this, cast 1 to u32 beforeperforming the shift, ensuring well-defined behavior.This change explicitly avoids any potential overflow by ensuring thatthe shift occurs on an unsigned 32-bit integer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libtasn1 > 0-0 (version in image is 4.13-150000.4.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rose: prevent integer overflows in rose_setsockopt()In case of possible unpredictably large arguments passed torose_setsockopt() and multiplied by extra values on top of that,integer overflows may occur.Do the safest minimum and fix these issues by checking thecontents of 'opt' and returning -EINVAL if they are too large. Also,switch to unsigned int and remove useless check for negative 'opt'in ROSE_IDLE case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add missing rcu read protection for procfs contentWhen the procfs content is generated for a bcm_op which is in the processto be removed the procfs output might show unreliable data (UAF).As the removal of bcm_op's is already implemented with rcu handling thispatch adds the missing rcu_read_lock() and makes sure the list entriesare properly removed under rcu protection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast racehuge_pmd_unshare() drops a reference on a page table that may havepreviously been shared across processes, potentially turning it into anormal page table used in another process in which unrelated VMAs canafterwards be installed.If this happens in the middle of a concurrent gup_fast(), gup_fast() couldend up walking the page tables of another process. While I don't see anyway in which that immediately leads to kernel memory corruption, it isreally weird and unexpected.Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),just like we do in khugepaged when removing page tables for a THPcollapse.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix error flow upon firmware failure for RQ destructionUpon RQ destruction if the firmware command fails which is thelast resource to be destroyed some SW resources were already cleanedregardless of the failure.Now properly rollback the object to its original state upon such failure.In order to avoid a use-after free in case someone tries to destroy theobject again, which results in the following kernel trace:refcount_t: underflow; use-after-free.WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : refcount_warn_saturate+0xf4/0x148lr : refcount_warn_saturate+0xf4/0x148sp : ffff80008b81b7e0x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37fx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fffx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: prevent overflow in lookup table allocationWhen calculating the lookup table size, ensure the followingmultiplication does not overflow:- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.Then, use check_mul_overflow() to multiply by bucket size and then usecheck_add_overflow() to the alignment for avx2 (if needed). Finally, addlt_size_check_overflow() helper and use it to consolidate this.While at it, replace leftover allocation using the GFP_KERNEL toGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix ktls panic with sockmap[ 2172.936997] ------------[ cut here ]------------[ 2172.936999] kernel BUG at lib/iov_iter.c:629!......[ 2172.944996] PKRU: 55555554[ 2172.945155] Call Trace:[ 2172.945299] [ 2172.945428] ? die+0x36/0x90[ 2172.945601] ? do_trap+0xdd/0x100[ 2172.945795] ? iov_iter_revert+0x178/0x180[ 2172.946031] ? iov_iter_revert+0x178/0x180[ 2172.946267] ? do_error_trap+0x7d/0x110[ 2172.946499] ? iov_iter_revert+0x178/0x180[ 2172.946736] ? exc_invalid_op+0x50/0x70[ 2172.946961] ? iov_iter_revert+0x178/0x180[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20[ 2172.947446] ? iov_iter_revert+0x178/0x180[ 2172.947683] ? iov_iter_revert+0x5c/0x180[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840[ 2172.948206] tls_sw_sendmsg+0x52/0x80[ 2172.948420] ? inet_sendmsg+0x1f/0x70[ 2172.948634] __sys_sendto+0x1cd/0x200[ 2172.948848] ? find_held_lock+0x2b/0x80[ 2172.949072] ? syscall_trace_enter+0x140/0x270[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170[ 2172.949595] ? find_held_lock+0x2b/0x80[ 2172.949817] ? syscall_trace_enter+0x140/0x270[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0[ 2172.951036] __x64_sys_sendto+0x24/0x30[ 2172.951382] do_syscall_64+0x90/0x170......After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,e.g., when the BPF program executes bpf_msg_push_data().If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,it will return -ENOSPC and attempt to roll back to the non-zero copylogic. However, during rollback, msg->msg_iter is reset, but sincemsg_pl->sg.size has been increased, subsequent executions will exceed theactual size of msg_iter.'''iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);'''The changes in this commit are based on the following considerations:1. When cork_bytes is set, rolling back to non-zero copy logic ispointless and can directly go to zero-copy logic.2. We can not calculate the correct number of bytes to revert msg_iter.Assume the original data is "abcdefgh" (8 bytes), and after 3 pushesby the BPF program, it becomes 11-byte data: "abc?de?fgh?".Then, we set cork_bytes to 6, which means the first 6 bytes have beenprocessed, and the remaining 5 bytes "?fgh?" will be cached until thelength meets the cork_bytes requirement.However, some data in "?fgh?" is not within 'sg->msg_iter'(but in msg_pl instead), especially the data "?" we pushed.So it doesn't seem as simple as just reverting through an offset ofmsg_iter.3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,the user-space send() doesn't return an error, and the returned length isthe same as the input length parameter, even if some data is cached.Additionally, I saw that the current non-zero-copy logic for handlingcorking is written as:'''line 1177else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end;'''So it's ok to just return 'copied' without error when a "cork" situationoccurs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: gpio: Fix the out-of-bounds access to drvdata::gpiodsdrvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. Butthe memory is allocated for only one pointer. This will lead toout-of-bounds access later in the code if 'config::ngpios' is > 1. Sofix the code to allocate enough memory to hold 'config::ngpios' of GPIOdescriptors.While at it, also move the check for memory allocation failure to be belowthe allocation to make it more readable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gem: Acquire references on GEM handles for framebuffersA GEM handle can be released while the GEM buffer object is attachedto a DRM framebuffer. This leads to the release of the dma-buf backingthe buffer object, if any. [1] Trying to use the framebuffer in furthermode-setting operations leads to a segmentation fault. Most easilyhappens with driver that use shadow planes for vmap-ing the dma-bufduring a page flip. An example is shown below.[ 156.791968] ------------[ cut here ]------------[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430[...][ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430[ 157.043420] Call Trace:[ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710[ 157.065567] ? dma_buf_vmap+0x224/0x430[ 157.069446] ? __warn.cold+0x58/0xe4[ 157.073061] ? dma_buf_vmap+0x224/0x430[ 157.077111] ? report_bug+0x1dd/0x390[ 157.080842] ? handle_bug+0x5e/0xa0[ 157.084389] ? exc_invalid_op+0x14/0x50[ 157.088291] ? asm_exc_invalid_op+0x16/0x20[ 157.092548] ? dma_buf_vmap+0x224/0x430[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10[ 157.110697] drm_gem_shmem_vmap+0x74/0x710[ 157.114866] drm_gem_vmap+0xa9/0x1b0[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0[ 157.123086] drm_gem_fb_vmap+0xab/0x300[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10[ 157.133032] ? lockdep_init_map_type+0x19d/0x880[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40[...][ 157.346424] ---[ end trace 0000000000000000 ]---Acquiring GEM handles for the framebuffer's GEM buffer objects preventsthis from happening. The framebuffer's cleanup later puts the handlereferences.Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM objectinstance") triggers the segmentation fault easily by using the dma-buffield more widely. The underlying issue with reference counting hasbeen present before.v2:- acquire the handle instead of the BO (Christian)- fix comment style (Christian)- drop the Fixes tag (Christian)- rename err_ gotos- add missing Link tag
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flightReject migration of SEV{-ES} state if either the source or destination VMis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in thesection between incrementing created_vcpus and online_vcpus. The bulk ofvCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUsin parallel, and so sev_info.es_active can get toggled from false=>true inthe destination VM after (or during) svm_vcpu_create(), resulting in anSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.The issue manifests most visibly as a crash when trying to free a vCPU'sNULL VMSA page in an SEV-ES VM, but any number of things can go wrong. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashingthe host is likely desirable due to the VMSA being consumed by hardware.E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write abogus VMSA page. Accessing P---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOVBefore disabling SR-IOV via config space accesses to the parent PF,sriov_disable() first removes the PCI devices representing the VFs.Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")such removal operations are serialized against concurrent remove andrescan using the pci_rescan_remove_lock. No such locking was ever addedin sriov_disable() however. In particular when commit 18f9e9d150fc("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI deviceremoval into sriov_del_vfs() there was still no locking around thepci_iov_remove_virtfn() calls.On s390 the lack of serialization in sriov_disable() may cause doubleremove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2.This is because in addition to sriov_disable() removing the VFs, theplatform also generates hot-unplug events for the VFs. This being thereverse operation to the hotplug events generated by sriov_enable() andhandled via pdev->no_vf_scan. And while the event processing takespci_rescan_remove_lock and checks whether the struct pci_dev still exists,the lack of synchronization makes this checking racy.Other races may also be possible of course though given that this lack oflocking persisted so long observable races seem very rare. Even on s390 thelist corruption was only observed with certain devices since the platformevents are only triggered by config accesses after the removal, so as longas the removal finished synchronously they would not race. Either way thelocking is missing so fix this by adding it to the sriov_del_vfs() helper.Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()including for the error case where pci_stop_and_remove_bus_device() iscalled without the PCI rescan-remove lock being held. Even in the non-errorcase, adding new PCI devices and buses should be serialized via the PCIrescan-remove lock. Add the necessary locking.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAFThere is a KASAN: slab-use-after-free read in btusb_disconnect().Calling "usb_driver_release_interface(&btusb_driver, data->intf)" willfree the btusb data associated with the interface. The same data isthen used later in the function, hence the UAF.Fix by moving the accesses to btusb data to before the data is free'd.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- net-tools > 0-0 (version in image is 2.0+git20170221.479bb4a-150000.5.13.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: potential integer overflow in usbg_make_tpg()The variable tpgt in usbg_make_tpg() is defined as unsigned long and isassigned to tpgt->tport_tpgt, which is defined as u16. This may cause aninteger overflow when tpgt is greater than USHRT_MAX (65535). Ihaven't tried to trigger it myself, but it is possible to trigger itby calling usbg_make_tpg() with a large value for tpgt.I modified the type of tpgt to match tpgt->tport_tpgt and adjusted therelevant code accordingly.This patch is similar to commit 59c816c1f24d ("vhost/scsi: potentialmemory corruption").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: ti_am335x_tsc - fix off-by-one error in wire_order validationThe current validation 'wire_order[i] > ARRAY_SIZE(config_pins)' allowswire_order[i] to equal ARRAY_SIZE(config_pins), which causes out-of-boundsaccess when used as index in 'config_pins[wire_order[i]]'.Since config_pins has 4 elements (indices 0-3), the valid range forwire_order should be 0-3. Fix the off-by-one error by using >= insteadof > in the validation check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.95.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failedWhen the ops_init() interface is invoked to initialize the net, butops->init() fails, data is released. However, the ptr pointer innet->gen is invalid. In this case, when nfqnl_nf_hook_drop() is invokedto release the net, invalid address access occurs.The process is as follows:setup_net() ops_init() data = kzalloc(...) ---> alloc "data" net_assign_generic() ---> assign "date" to ptr in net->gen ... ops->init() ---> failed ... kfree(data); ---> ptr in net->gen is invalid ... ops_exit_list() ... nfqnl_nf_hook_drop() *q = nfnl_queue_pernet(net) ---> q is invalidThe following is the Call Trace information:BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280Read of size 8 at addr ffff88810396b240 by task ip/15855Call Trace:dump_stack_lvl+0x8e/0xd1print_report+0x155/0x454kasan_report+0xba/0x1f0nfqnl_nf_hook_drop+0x264/0x280nf_queue_nf_hook_drop+0x8b/0x1b0__nf_unregister_net_hook+0x1ae/0x5a0nf_unregister_net_hooks+0xde/0x130ops_exit_list+0xb0/0x170setup_net+0x7ac/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Allocated by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30__kasan_kmalloc+0xa1/0xb0__kmalloc+0x49/0xb0ops_init+0xe7/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Freed by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30kasan_save_free_info+0x2a/0x40____kasan_slab_free+0x155/0x1b0slab_free_freelist_hook+0x11b/0x220__kmem_cache_free+0xa4/0x360ops_init+0xb9/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential OOBs in smb2_parse_contexts()Validate offsets and lengths before dereferencing create contexts insmb2_parse_contexts().This fixes following oops when accessing invalid create contexts fromserver: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: check send stream number after wait_for_sndbufThis patch fixes a corner case where the asoc out stream count may changeafter wait_for_sndbuf.When the main thread in the client starts a connection, if its out streamcount is set to N while the in stream count in the server is set to N - 2,another thread in the client keeps sending the msgs with stream numberN - 1, and waits for sndbuf before processing INIT_ACK.However, after processing INIT_ACK, the out stream count in the client isshrunk to N - 2, the same to the in stream count in the server. The crashoccurs when the thread waiting for sndbuf is awake and sends the msg in anon-existing stream(N - 1), the call trace is as below: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline] sock_sendmsg+0xde/0x190 net/socket.c:745The fix is to add an unlikely check for the send stream number after thethread wakes up from the wait_for_sndbuf.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: do not update mtu if msg_max is too small in mtu negotiationWhen doing link mtu negotiation, a malicious peer may send Activate msgwith a very small mtu, e.g. 4 in Shuang's testing, without checking forthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), thenn->links[bearer_id].mtu is set to 4294967228, which is a overflow of'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4!And with tipc_link_entry.mtu 4294967228, a huge skb was allocated innamed_distribute(), and when purging it in tipc_link_xmit(), a crashwas even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),and not updating mtu if it is too small.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix out-of-bounds access in ipv6_find_tlv()optlen is fetched without checking whether there is more than one byte to parse.It can lead to out-of-bounds access.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hexApparently the hex passphrase mechanism does not work on newerchips/firmware (e.g. BCM4387). It seems there was a simple way ofpassing it in binary all along, so use that and avoid the hexification.OpenBSD has been doing it like this from the beginning, so this shouldwork on all chips.Also clear the structure before setting the PMK. This was leakinguninitialized stack contents to the device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_api: remove block_cb from driver_list before freeingError handler of tcf_block_bind() frees the whole bo->cb_list on error.However, by that time the flow_block_cb instances are already in the driverlist because driver ndo_setup_tc() callback is called before that up thecall chain in tcf_block_offload_cmd(). This leaves dangling pointers tofreed objects in the list and causes use-after-free[0]. Fix it by alsoremoving flow_block_cb instances from driver_list before deallocating them.[0]:[ 279.868433] ==================================================================[ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0[ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963[ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4[ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 279.876295] Call Trace:[ 279.876882] [ 279.877413] dump_stack_lvl+0x33/0x50[ 279.878198] print_report+0xc2/0x610[ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.879994] kasan_report+0xae/0xe0[ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core][ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0[ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0[ 279.885037] ? tcf_block_setup+0x6b0/0x6b0[ 279.885901] ? mutex_lock+0x7d/0xd0[ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0[ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress][ 279.888846] tcf_block_get_ext+0x61c/0x1200[ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress][ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress][ 279.891701] qdisc_create+0x401/0xea0[ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470[ 279.893473] tc_modify_qdisc+0x6f7/0x16d0[ 279.894344] ? tc_get_qdisc+0xac0/0xac0[ 279.895213] ? mutex_lock+0x7d/0xd0[ 279.896005] ? __mutex_lock_slowpath+0x10/0x10[ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0[ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.898672] ? __sys_sendmsg+0xb5/0x140[ 279.899494] ? do_syscall_64+0x3d/0x90[ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 279.901337] ? kasan_save_stack+0x2e/0x40[ 279.902177] ? kasan_save_stack+0x1e/0x40[ 279.903058] ? kasan_set_track+0x21/0x30[ 279.903913] ? kasan_save_free_info+0x2a/0x40[ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0[ 279.905741] ? kmem_cache_free+0x179/0x400[ 279.906599] netlink_rcv_skb+0x12c/0x360[ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.908360] ? netlink_ack+0x1550/0x1550[ 279.909192] ? rhashtable_walk_peek+0x170/0x170[ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390[ 279.911086] ? _copy_from_iter+0x3d6/0xc70[ 279.912031] netlink_unicast+0x553/0x790[ 279.912864] ? netlink_attachskb+0x6a0/0x6a0[ 279.913763] ? netlink_recvmsg+0x416/0xb50[ 279.914627] netlink_sendmsg+0x7a1/0xcb0[ 279.915473] ? netlink_unicast+0x790/0x790[ 279.916334] ? iovec_from_user.part.0+0x4d/0x220[ 279.917293] ? netlink_unicast+0x790/0x790[ 279.918159] sock_sendmsg+0xc5/0x190[ 279.918938] ____sys_sendmsg+0x535/0x6b0[ 279.919813] ? import_iovec+0x7/0x10[ 279.920601] ? kernel_sendmsg+0x30/0x30[ 279.921423] ? __copy_msghdr+0x3c0/0x3c0[ 279.922254] ? import_iovec+0x7/0x10[ 279.923041] ___sys_sendmsg+0xeb/0x170[ 279.923854] ? copy_msghdr_from_user+0x110/0x110[ 279.924797] ? ___sys_recvmsg+0xd9/0x130[ 279.925630] ? __perf_event_task_sched_in+0x183/0x470[ 279.926656] ? ___sys_sendmsg+0x170/0x170[ 279.927529] ? ctx_sched_in+0x530/0x530[ 279.928369] ? update_curr+0x283/0x4f0[ 279.929185] ? perf_event_update_userpage+0x570/0x570[ 279.930201] ? __fget_light+0x57/0x520[ 279.931023] ? __switch_to+0x53d/0xe70[ 27---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set page extent mapped after read_folio in relocate_one_pageOne of the CI runs triggered the following panic assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 sp : ffff800093213720 x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_set_dirty+0x38/0xa0 btrfs_page_set_dirty+0x58/0x88 relocate_one_page+0x204/0x5f0 relocate_file_extent_cluster+0x11c/0x180 relocate_data_extent+0xd0/0xf8 relocate_block_group+0x3d0/0x4e8 btrfs_relocate_block_group+0x2d8/0x490 btrfs_relocate_chunk+0x54/0x1a8 btrfs_balance+0x7f4/0x1150 btrfs_ioctl+0x10f0/0x20b8 __arm64_sys_ioctl+0x120/0x11d8 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x158 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)This is the same problem outlined in 17b17fcd6d44 ("btrfs:set_page_extent_mapped after read_folio in btrfs_cont_expand") , and thefix is the same. I originally looked for the same pattern elsewhere inour code, but mistakenly skipped over this code because I saw the pagecache readahead before we set_page_extent_mapped, not realizing thatthis was only in the !page case, that we can still end up with a!uptodate page and then do the btrfs_read_folio further down.The fix here is the same as the above mentioned patch, move theset_page_extent_mapped call to after the btrfs_read_folio() block tomake sure that we have the subpage blocksize stuff setup properly beforeusing the page.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).
-
Description: A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: confirm multicast packets before passing them up the stackconntrack nf_confirm logic cannot handle cloned skbs referencingthe same nf_conn entry, which will happen for multicast (broadcast)frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.The Macvlan broadcast worker and normal confirm path will race.This race will not happen if step 2 already confirmed a clone. In thatcase later steps perform skb_clone() with skb->_nfct already confirmed (inhash table). This works fine.But such confirmation won't happen when eb/ip/nftables rules dropped thepackets before they reached the nf_confirm step in postrouting.Pablo points out that nf_conntrack_bridge doesn't allow use of statefulnat, so we can safely discard the nf_conn entry and let inet callconntrack again.This doesn't work for bridge netfilter: skb could have a nattransformation. Also bridge nf prevents re-invocation of inet preroutingvia 'sabotage_in' hook.Work around this problem by explicit confirmation of the entry at LOCAL_INtime, before upper layer has a chance to clone the unconfirmed entry.The downside is that this disables NAT and conntrack helpers.Alternative fix would be to add locking to all code parts that deal withunconfirmed packets, but even if that could be done in a sane way thisopens up other problems, for example:-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5For multicast case, only one of such conflicting mappings will becreated, conntrack only handles 1:1 NAT mappings.Users should set create a setup that explicitly marks such trafficNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypassthem, ruleset might have accept rules for untracked traffic already,so user-visible behaviour would change.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix mptcp DSS corruption due to large pmtu xmitSyzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.69.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools < 2.70.5-150400.3.29.1 (version in image is 2.70.5-150400.3.23.1).
-
Description: User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- krb5 > 0-0 (version in image is 1.20.1-150500.3.17.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- iputils > 0-0 (version in image is 20221126-150500.3.14.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctlyThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have aLS_NLA_TYPE_DGID attribute, it is invalid if it does not.Use the nl parsing logic properly and call nla_parse_deprecated() to fillthe nlattrs array and then directly index that array to get the data forthe DGID. Just fail if it is NULL.Remove the for loop searching for the nla, and squash the validation andparsing into one function.Fixes an uninitialized read from the stack triggered by userspace if itdoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVEquery. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: There is a defect in the CPython "tarfile" module affecting the "TarFile" extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. This vulnerability can be mitigated by including the following patch after importing the "tarfile" module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).
-
Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctlHulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock heldby ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can beconcurrent.ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.ubi_detach is bug-free because it uses reference counting to preventconcurrency. However, uif_init and uif_close in ubi_attach may race withubi_cdev_ioctl.uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_delAnd uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double freeThe cause of this problem is that commit 714fb87e8bc0 make device"available" before it becomes accessible via sysfs. Therefore, weroll back the modification. We will fix the race condition betweenubi device creation and udev by removing ubi_get_device invol_attribute_show and dev_attribute_show.This avoids accessinguninitialized ubi_devices[ubi_num].ubi_get_device is used to prevent devices from being deleted duringsysfs execution. However, now kernfs ensures that devices will notbe deleted before all reference counting are released.The key process is shown in the following stack.device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: Fix UAF in destroy()Dm_cache also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in destroy().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Use different devices for resource allocation and DT lookupFollowing by the below discussion, there's the potential UAF issuebetween regulator and mfd.https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/From the analysis of YingliangCPU A |CPU Bmt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data()i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register()It's common to use mfd core to create child device for the regulator.In order to do the DT lookup for init data, the child that registeredthe regulator would pass its parent as the parameter. And this causesinit data resource allocated to its parent, not itself. The issue happenwhen parent device is going to release and regulator core is still doingsome operation of init data constraint for the regulator of child device.To fix it, this patch expand 'regulator_register' API to use thedifferent devices for init data allocation and DT lookup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add bounds checking in get_max_inline_xattr_value_size()Normally the extended attributes in the inode body would have beenchecked when the inode is first opened, but if someone is writing tothe block device while the file system is mounted, it's possible forthe inode table to get corrupted. Add bounds checking to avoidreading beyond the end of allocated memory if this happens.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Sync IRQ works before buffer destructionIf something was written to the buffer just before destruction,it may be possible (maybe not in a real system, but it didhappen in ARCH=um with time-travel) to destroy the ringbufferbefore the IRQ work ran, leading this KASAN report (or a crashwithout KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00)Add the appropriate irq_work_sync() so the work finishes beforethe buffers are destroyed.Prior to the commit in the Fixes tag below, there was only asingle global IRQ work, so this issue didn't exist.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: exc3000 - properly stop timer on shutdownWe need to stop the timer on driver unbind or probe failures, otherwisewe get UAF/Oops.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race conditionmptlan_probe() calls mpt_register_lan_device() which initializes the&priv->post_buckets_task workqueue. A call tompt_lan_wake_post_buckets_task() will subsequently start the work.During driver unload in mptlan_remove() the following race may occur:CPU0 CPU1 |mpt_lan_post_receive_buckets_work()mptlan_remove() | free_netdev() | kfree(dev); | | | dev->mtu | //useFix this by finishing the work prior to cleaning up in mptlan_remove().[mkp: we really should remove mptlan instead of attempting to fix it]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:topology: Keep the cpumask unchanged when printing cpumapDuring fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2The call trace shows that kvasprintf() reported this warning during theprinting of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.If the core_cpumask is modified between steps (1) and (3), the lengthsobtained in these two steps may not match. Indeed our test includes cpuhotplugging, which should modify core_cpumask while printing.To fix this issue, cache the cpumask into a temporary variable beforecalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchangedduring the printing process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: vmclock: Set driver data before its usageIf vmclock_ptp_register() fails during probing, vmclock_remove() iscalled to clean up the ptp clock and misc device.It uses dev_get_drvdata() to access the vmclock state.However the driver data is not yet set at this point.Assign the driver data earlier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Don't reference skb after sending to VIOSPreviously, after successfully flushing the xmit buffer to VIOS,the tx_bytes stat was incremented by the length of the skb.It is invalid to access the skb memory after sending the buffer tothe VIOS because, at any point after sending, the VIOS can triggeran interrupt to free this memory. A race between reading skb->lenand freeing the skb is possible (especially during LPM) and willresult in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Set fb_display[i]->mode to NULL when the mode is releasedRecently, we discovered the following issue through syzkaller:BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0Read of size 4 at addr ff11000001b3c69c by task syz.xxx...Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eBased on experimentation and analysis, during framebuffer unregistration,only the memory of fb_info->modelist is freed, without setting thecorresponding fb_display[i]->mode to NULL for the freed modes. This leadsto UAF issues during subsequent accesses. Here's an example of reproductionsteps:1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1;2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);3. Switch console from fb to VGA (to allow normal rmmod of the ko);4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[];5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.Add a check in do_unregister_framebuffer(): if the mode to be freed existsin fb_display[], set the corresponding mode pointer to NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_mr: Fix use-after-free when updating multicast route statsCited commit added a dedicated mutex (instead of RTNL) to protect themulticast route list, so that it will not change while the driverperiodically traverses it in order to update the kernel about multicastroute stats that were queried from the device.One instance of list entry deletion (during route replace) was missedand it can result in a use-after-free [1].Fix by acquiring the mutex before deleting the entry from the list andreleasing it afterwards.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]Call Trace: dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: lkkbd - disable pending work before freeing devicelkkbd_interrupt() schedules lk->tq via schedule_work(), and the workhandler lkkbd_reinit() dereferences the lkkbd structure and itsserio/input_dev fields.lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbdstructure without preventing the reinit work from being queued againuntil serio_close() returns. This can allow the work handler to runafter the structure has been freed, leading to a potential use-after-free.Use disable_work_sync() instead of cancel_work_sync() to ensure thereinit work cannot be re-queued, and call it both in lkkbd_disconnect()and in lkkbd_connect() error paths after serio_open().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: stm32: sai: fix OF node leak on probeThe reference taken to the sync provider OF node when probing theplatform device is currently only dropped if the set_sync() callbackfails during DAI probe.Make sure to drop the reference on platform probe failures (e.g. probedeferral) and on driver unbind.This also avoids a potential use-after-free in case the DAI is everreprobed without first rebinding the platform driver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTSUBSAN complains about array-index-out-of-bounds:[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010[ 1.980718] kernel: Call Trace:[ 1.980721] kernel: [ 1.980723] kernel: show_stack+0x52/0x58[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f[ 1.980734] kernel: dump_stack+0x10/0x12[ 1.980736] kernel: ubsan_epilogue+0x9/0x45[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci][ 1.980748] kernel: ata_qc_issue+0x135/0x240[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580[ 1.980754] kernel: ? vprintk_default+0x1d/0x20[ 1.980759] kernel: ata_exec_internal+0x67/0xa0[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci][ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci][ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci][ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci][ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0[ 1.980813] kernel: scsi_error_handler+0xa1/0x180[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0[ 1.980820] kernel: kthread+0x12a/0x150[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50[ 1.980826] kernel: ret_from_fork+0x22/0x30[ 1.980831] kernel: This happens because sata_pmp_init_links() initialize link->pmp up toSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.I can't find the maximum Enclosure Management ports specified in AHCIspec v1.3.1, but "12.2.1 LED message type" states that "Port MultiplierInformation" can utilize 4 bits, which implies it can support up to 16ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve theissue.BugLink: https://bugs.launchpad.net/bugs/1970074
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: si470x: Fix use-after-free in si470x_int_in_callback()syzbot reported use-after-free in si470x_int_in_callback() [1]. Thisindicates that urb->context, which contains struct si470x_deviceobject, is freed when si470x_int_in_callback() is called.The cause of this issue is that si470x_int_in_callback() is called forfreed urb.si470x_usb_driver_probe() calls si470x_start_usb(), which then callsusb_submit_urb() and si470x_start(). If si470x_start_usb() fails,si470x_usb_driver_probe() doesn't kill urb, but it just frees structsi470x_device object, as depicted below:si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urbThis patch fixes this issue by killing urb when si470x_start_usb()fails and urb is submitted. If si470x_start_usb() fails and urb isnot submitted, i.e. submitting usb fails, it just frees structsi470x_device object.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/chrome: fix memory corruption in ioctlIf "s_mem.bytes" is larger than the buffer size it leads to memorycorruption.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Don't disable x2APIC if lockedThe APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC(or x2APIC). X2APIC mode is mostly compatible with legacy APIC, butit disables the memory-mapped APIC interface in favor of one that usesMSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.The MMIO/xAPIC interface has some problems, most notably the APIC LEAK[1]. This bug allows an attacker to use the APIC MMIO interface toextract data from the SGX enclave.Introduce support for a new feature that will allow the BIOS to lockthe APIC in x2APIC mode. If the APIC is locked in x2APIC mode and thekernel tries to disable the APIC or revert to legacy APIC mode a GPfault will occur.Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handlethe new locked mode when the LEGACY_XAPIC_DISABLED bit is set bypreventing the kernel from trying to disable the x2APIC.On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX areenabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. Iflegacy APIC is required, then it SGX and TDX need to be disabled in theBIOS.[1]: https://aepicleak.com/aepicleak.pdf
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/sit: use DEV_STATS_INC() to avoid data-racessyzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_errorconcurrently.This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()is not protected by a spinlock.While original KCSAN report was about tx path, rx path has the same issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, whichcan lead to memory corruption. The only place we have found where thishappens is in the swapoff path. This case can be described as below:core 0 core 1swapoffdel_from_avail_list(si) waitingtry lock si->lock acquire swap_avail_lock and re-add si into swap_avail_headacquire si->lock but missing si already being added again, and continuingto clear SWP_WRITEOK, etc.It can be easily found that a massive warning messages can be triggeredinside get_swap_pages() by some special cases, for example, we callmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,run much swapon-swapoff operations (e.g. stress-ng-swap).However, in the worst case, panic can be caused by the above scene. Inswapoff(), the memory used by si could be kept in swap_info[] afterturning off a swap. This means memory corruption will not be causedimmediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled)------------[ cut here ]------------top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451aprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8dnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451aWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70Modules linked in: rfkill(E) crct10dif_ce(E)...CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)pc : plist_check_prev_next_node+0x50/0x70lr : plist_check_prev_next_node+0x50/0x70sp : ffff0018009d3c30x29: ffff0018009d3c40 x28: ffff800011b32a98x27: 0000000000000000 x26: ffff001803908000x25: ffff8000128ea088 x24: ffff800011b32a48x23: 0000000000000028 x22: ffff001800875c00x21: ffff800010f9e520 x20: ffff001800875c00x19: ffff001800fdc6e0 x18: 0000000000000030x17: 0000000000000000 x16: 0000000000000000x15: 0736076307640766 x14: 0730073007380731x13: 0736076307640766 x12: 0730073007380731x11: 000000000004058d x10: 0000000085a85b76x9 : ffff8000101436e4 x8 : ffff800011c8ce08x7 : 0000000000000000 x6 : 0000000000000001x5 : ffff0017df9ed338 x4 : 0000000000000001x3 : ffff8017ce62a000 x2 : ffff0017df9ed340x1 : 0000000000000000 x0 : 0000000000000000Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180irq event stamp: 2082270Now, si->lock locked before calling 'del_from_avail_list()' to make sureother thread see the si had been deleted and SWP_WRITEOK cleared together,will not reinsert again.This problem exists in versions after stable 5.10.y.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix possible double unlock when moving a directory
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Detect system inodes linked into directory hierarchyWhen UDF filesystem is corrupted, hidden system inodes can be linkedinto directory hierarchy which is an avenue for further seriouscorruption of the filesystem and kernel confusion as noticed by syzbotfuzzed images. Refuse to access system inodes linked into directoryhierarchy and vice versa.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()BUG_ON() will be triggered when writing files concurrently,because the same page is writtenback multiple times.1597 void folio_end_writeback(struct folio *folio)1598 { ......1618 if (!__folio_end_writeback(folio))1619 BUG(); ......1625 }kernel BUG at mm/filemap.c:1619!Call Trace: f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50 __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Below is the concurrency scenario:[Process A] [Process B] [Process C]f2fs_write_raw_pages() - redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [1st writeback] ..... - unlock page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback() [2st writeback]This problem was introduced by the previous commit 7377e853967b ("f2fs:compress: fix potential deadlock of compress file"). All pagelocks werereleased in f2fs_write_raw_pages(), but whether the page wasin the writeback state was ignored in the subsequent writing process.Let's fix it by waiting for the page to writeback before writing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/type1: fix cap_migration information leakFix an information leak where an uninitialized hole in structvfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.The definition of struct vfio_iommu_type1_info_cap_migration contains a hole asshown in this pahole(1) output: struct vfio_iommu_type1_info_cap_migration { struct vfio_info_cap_header header; /* 0 8 */ __u32 flags; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __u64 pgsize_bitmap; /* 16 8 */ __u64 max_dirty_bitmap_size; /* 24 8 */ /* size: 32, cachelines: 1, members: 4 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ };The cap_mig variable is filled in without initializing the hole: static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps) { struct vfio_iommu_type1_info_cap_migration cap_mig; cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION; cap_mig.header.version = 1; cap_mig.flags = 0; /* support minimum pgsize */ cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap); cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX; return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig)); }The structure is then copied to a temporary location on the heap. At this pointit's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspacelater: int vfio_info_add_capability(struct vfio_info_cap *caps, struct vfio_info_cap_header *cap, size_t size) { struct vfio_info_cap_header *header; header = vfio_info_cap_add(caps, size, cap->id, cap->version); if (IS_ERR(header)) return PTR_ERR(header); memcpy(header + 1, cap + 1, size - sizeof(*header)); return 0; }This issue was found by code inspection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always release netdev hooks from notifierThis reverts "netfilter: nf_tables: skip netdev events generated on netns removal".The problem is that when a veth device is released, the veth releasecallback will also queue the peer netns device for removal.Its possible that the peer netns is also slated for removal. In thiscase, the device memory is already released before the pre_exit hook ofthe peer netns runs:BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45Workqueue: netns cleanup_netCall Trace: nf_hook_entry_head+0x1b8/0x1d0 __nf_unregister_net_hook+0x76/0x510 nft_netdev_unregister_hooks+0xa0/0x220 __nft_release_hook+0x184/0x490 nf_tables_pre_exit_net+0x12f/0x1b0 ..Order is:1. First netns is released, veth_dellink() queues peer netns device for removal2. peer netns is queued for removal3. peer netns device is released, unreg event is triggered4. unreg event is ignored because netns is going down5. pre_exit hook calls nft_netdev_unregister_hooks but device memory might be free'd already.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix a memory corruption in extended buffer descriptor modeFor quite some time we were chasing a bug which looked like a suddenpermanent failure of networking and mmc on some of our devices.The bug was very sensitive to any software changes and even more toany kernel debug options.Finally we got a setup where the problem was reproducible withCONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:[ 16.992082] ------------[ cut here ]------------[ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes][ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900[ 17.018977] Modules linked in: xxxxx[ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28[ 17.045345] Hardware name: xxxxx[ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)[ 17.054322] pc : check_unmap+0x6a0/0x900[ 17.058243] lr : check_unmap+0x6a0/0x900[ 17.062163] sp : ffffffc010003c40[ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c[ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800[ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8[ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750[ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000[ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010[ 17.097343] x17: 0000000000000000 x16: 0000000000000000[ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720[ 17.107959] x13: 0720072007200720 x12: 0720072007200720[ 17.113261] x11: 0720072007200720 x10: 0720072007200720[ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d[ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098[ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000[ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370[ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000[ 17.145082] Call trace:[ 17.147524] check_unmap+0x6a0/0x900[ 17.151091] debug_dma_unmap_page+0x88/0x90[ 17.155266] gem_rx+0x114/0x2f0[ 17.158396] macb_poll+0x58/0x100[ 17.161705] net_rx_action+0x118/0x400[ 17.165445] __do_softirq+0x138/0x36c[ 17.169100] irq_exit+0x98/0xc0[ 17.172234] __handle_domain_irq+0x64/0xc0[ 17.176320] gic_handle_irq+0x5c/0xc0[ 17.179974] el1_irq+0xb8/0x140[ 17.183109] xiic_process+0x5c/0xe30[ 17.186677] irq_thread_fn+0x28/0x90[ 17.190244] irq_thread+0x208/0x2a0[ 17.193724] kthread+0x130/0x140[ 17.196945] ret_from_fork+0x10/0x20[ 17.200510] ---[ end trace 7240980785f81d6f ]---[ 237.021490] ------------[ cut here ]------------[ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b[ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240[ 237.041802] Modules linked in: xxxxx[ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28[ 237.068941] Hardware name: xxxxx[ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)[ 237.077900] pc : add_dma_entry+0x214/0x240[ 237.081986] lr : add_dma_entry+0x214/0x240[ 237.086072] sp : ffffffc010003c30[ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00[ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0[ 237.099987] x25: 0000000000000002 x24: 0000000000000000[ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00[ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600[ 237.115897] x19: 00000000ffffffef x18: 0000000000000010[ 237.121201] x17: 0000000000000000 x16: 0000000000000000[ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720[ 237.131807] x13: 0720072007200720 x12: 0720072007200720[ 237.137111] x11: 0720072007200720 x10: 0720072007200720[ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259[ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000[ 237.15302---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix a race condition in retrieve_depsThere's a race condition in the multipath target when retrieve_depsraces with multipath_message calling dm_get_device and dm_put_device.retrieve_deps walks the list of open devices without holding any lockbut multipath may add or remove devices to the list while it isrunning. The end result may be memory corruption or use-after-freememory access.See this description of a UAF with multipath_message():https://listman.redhat.com/archives/dm-devel/2022-October/052373.htmlFix this bug by introducing a new rw semaphore "devices_lock". We grabdevices_lock for read in retrieve_deps and we grab it for write indm_get_device and dm_put_device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).
-
Description: A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check smcd_v2_ext_offset when receiving proposal msgWhen receiving proposal msg in server, the field smcd_v2_ext_offset inproposal msg is from the remote client and can not be fully trusted.Once the value of smcd_v2_ext_offset exceed the max value, there hasthe chance to access wrong address, and crash may happen.This patch checks the value of smcd_v2_ext_offset before using it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msgWhen receiving proposal msg in server, the fields v2_ext_offset/eid_cnt/ism_gid_cnt in proposal msg are from the remote clientand can not be fully trusted. Especially the field v2_ext_offset,once exceed the max value, there has the chance to access wrongaddress, and crash may happen.This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cntbefore using them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix out-of-bounds access of directory entriesIn the case of the directory size is greater than or equal tothe cluster size, if start_clu becomes an EOF cluster(an invalidcluster) due to file system corruption, then the directory entrywhere ei->hint_femp.eidx hint is outside the directory, resultingin an out-of-bounds access, which may cause further file systemcorruption.This commit adds a check for start_clu, if it is an invalid cluster,the file or directory will be treated as empty.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.69.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-sff: Ensure that we cannot write outside the allocated bufferreveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_lenset to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set toATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() towrite outside the allocated buffer, overwriting random memory.While a ATA device is supposed to abort a ATA_NOP command, there does seemto be a bug either in libata-sff or QEMU, where either this status is notset, or the status is cleared before read by ata_sff_hsm_move().Anyway, that is most likely a separate bug.Looking at __atapi_pio_bytes(), it already has a safety check to ensurethat __atapi_pio_bytes() cannot write outside the allocated buffer.Add a similar check to ata_pio_sector(), such that also ata_pio_sector()cannot write outside the allocated buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: update channel list in reg notifier instead reg workerCurrently when ath11k gets a new channel list, it will be processedaccording to the following steps:1. update new channel list to cfg80211 and queue reg_work.2. cfg80211 handles new channel list during reg_work.3. update cfg80211's handled channel list to firmware byath11k_reg_update_chan_list().But ath11k will immediately execute step 3 after reg_work is justqueued. Since step 2 is asynchronous, cfg80211 may not have completedhandling the new channel list, which may leading to an out-of-boundswrite error:BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_listCall Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0Should ensure step 2 is completely done before executing step 3. ThusWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,cfg80211 will notify ath11k after step 2 is done.So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 willnotify ath11k after step 2 is done. At this time, there will be noKASAN bug during the execution of the step 3.[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Avoid race in open_cached_dir with lease breaksA pre-existing valid cfid returned from find_or_create_cached_dir mightrace with a lease break, meaning open_cached_dir doesn't consider itvalid, and thinks it's newly-constructed. This leaks a dentry referenceif the allocation occurs before the queued lease break work runs.Avoid the race by extending holding the cfid_list_lock acrossfind_or_create_cached_dir and when the result is checked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add locking for bcm_op runtime updatesThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames viahrtimer. The content and also the length of the sequence can be changedresp reduced at runtime where the 'currframe' counter is then set to zero.Although this appeared to be a safe operation the updates of 'currframe'can be triggered from user space and hrtimer context in bcm_can_tx().Anderson Nascimento created a proof of concept that triggered a KASANslab-out-of-bounds read access which can be prevented with a spin_lock_bh.At the rework of bcm_can_tx() the 'count' variable has been moved intothe protected section as this variable can be modified from both contextstoo.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio: break and reset virtio devices on device_shutdown()Hongyu reported a hang on kexec in a VM. QEMU reported invalid memoryaccesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ...It was traced down to virtio-console. Kexec works fine if virtio-consoleis not in use.The issue is that virtio-console continues to write to the MMIO even afterunderlying virtio-pci device is reset.Additionally, Eric noticed that IOMMUs are reset before devices, ifdevices are not reset on shutdown they continue to poke at guest memoryand get errors from the IOMMU. Some devices get wedged then.The problem can be solved by breaking all virtio devices on virtiobus shutdown, then resetting them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful.2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]---To fix this, check for !dma_mapping_error() before callingdma_unmap_single() on the "theend_iv" path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a race between renames and directory loggingWe have a race between a rename and directory inode logging that if ithappens and we crash/power fail before the rename completes, the next timethe filesystem is mounted, the log replay code will end up deleting thefile that was being renamed.This is best explained following a step by step analysis of an interleavingof steps that lead into this situation.Consider the initial conditions:1) We are at transaction N;2) We have directories A and B created in a past transaction (< N);3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N);4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N).The steps leading to a file loss are the following and for all of them weare under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree;10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost.The issue wouldn't happen if task B synced the log only after task Acalled btrfs_log_new_name(), which would update the log with the new namefor inode Y ("A/bar").Fix this by pinning the log root during renames before removing the olddirectory entry, and unpinning af---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: Fix use-after-free in acpi_video_switch_brightness()The switch_brightness_work delayed work accesses device->brightnessand device->backlight, freed by acpi_video_dev_unregister_backlight()during device removal.If the work executes after acpi_video_bus_unregister_backlight()frees these resources, it causes a use-after-free whenacpi_video_switch_brightness() dereferences device->brightness ordevice->backlight.Fix this by calling cancel_delayed_work_sync() for each device'sswitch_brightness_work in acpi_video_bus_remove_notify_handler()after removing the notify handler that queues the work. This ensuresthe work completes before the memory is freed.[ rjw: Changelog edit ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()Use RCU to avoid a pair of atomic operations and a potentialUAF on dst_dev()->flags.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingThe Supported Rates IE length from an incoming Association Request framewas used directly as the memcpy() length when copying into a fixed-size16-byte stack buffer (supportRate). A malicious station can advertise anIE length larger than 16 bytes, causing a stack buffer overflow.Clamp ie_len to the buffer size before copying the Supported Rates IE,and correct the bounds check when merging Extended Supported Rates toprevent a second potential overflow.This prevents kernel stack corruption triggered by malformed associationrequests.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make decode_pool() more resilient against corrupted osdmapsIf the osdmap is (maliciously) corrupted such that the encoded lengthof ceph_pg_pool envelope is less than what is expected for a particularencoding version, out-of-bounds reads may ensue because the only boundscheck that is there is based on that length value.This patch adds explicit bounds checks for each field that is decodedor skipped.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_runIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0 CPU1mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_workmtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //useIf we close the file descriptor, which will call mtk_jpeg_release,it will have a similar sequence.Fix this bug by starting timeout worker only if started jpegdec workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib: cpu_rmap: Avoid use after free on rmap->obj array entriesWhen calling irq_set_affinity_notifier() with NULL at the notifyargument, it will cause freeing of the glue pointer in thecorresponding array entry but will leave the pointer in the array. Asubsequent call to free_irq_cpu_rmap() will try to free this entry againleading to possible use after free.Fix that by setting NULL to the array entry and checking that we havenon-zero at the array entry when iterating over the array infree_irq_cpu_rmap().The current code does not suffer from this since there are no caseswhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for thenotify arg) is called, followed by a call to free_irq_cpu_rmap() so wedon't hit and issue. Subsequent patches in this series excersize thisflow, hence the required fix.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_ptp_openWhen kvzalloc_node or kvzalloc failed in mlx5e_ptp_open, the memorypointed by "c" or "cparams" is not freed, which can lead to a memoryleak. Fix by freeing the array in the error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix an uninit variable access bug in __ip6_make_skb()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because icmp6hdr does not in skb linear region under the scenarioof SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly willtrigger the uninit variable access bug.Use a local variable icmp6_type to carry the correct value in differentscenarios.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Tear down vGIC on failed vCPU creationIf kvm_arch_vcpu_create() fails to share the vCPU page with thehypervisor, we propagate the error back to the ioctl but leave thevGIC vCPU data initialised. Note only does this leak the correspondingmemory when the vCPU is destroyed but it can also lead to use-after-freeif the redistributor device handling tries to walk into the vCPU.Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that thevGIC vCPU structures are destroyed on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- perl > 0-0 (version in image is 5.26.1-150300.17.20.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: greybus: audio_helper: remove unused and wrong debugfs usageIn the greybus audio_helper code, the debugfs file for the dapm has thepotential to be removed and memory will be leaked. There is also thevery real potential for this code to remove ALL debugfs entries from thesystem, and it seems like this is what will really happen if this codeever runs. This all is very wrong as the greybus audio driver did notcreate this debugfs file, the sound core did and controls the lifespanof it.So remove all of the debugfs logic from the audio_helper code as there'sno way it could be correct. If this really is needed, it can come backwith a fixup for the incorrect usage of the debugfs_lookup() call whichis what caused this to be noticed at all.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: jfs: fix shift-out-of-bounds in dbAllocAGSyzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. Theunderlying bug is the missing check of bmp->db_agl2size. The field canbe greater than 64 and trigger the shift-out-of-bounds.Fix this bug by adding a check of bmp->db_agl2size in dbMount since thisfield is used in many following functions. The upper bound for thisfield is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.Note that, for maintenance, I reorganized error handling code of dbMount.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: prevent overflow while calculating wait timeThere is a problem found by code review in tg_with_in_bps_limit() that'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem bycalling mul_u64_u64_div_u64() instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()In az6007_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach az6007_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob writeWhen the oob buffer length is not in multiple of words, the oob writefunction does out-of-bounds read on the oob source buffer at the lastiteration. Fix that by always checking length limit on the oob bufferread and fill with 0xff when reaching the end of the buffer to the oobregisters.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-boundsFix a stack-out-of-bounds read in brcmfmac that occurswhen 'buf' that is not null-terminated is passed as an argument ofstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled witha CLM version string by memcpy() in brcmf_fil_iovar_data_get().Ensure buf is null-terminated.Found by a modified version of syzkaller.[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22[ 33.021554][ T1896] ==================================================================[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896[ 33.023852][ T1896][ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event[ 33.026581][ T1896] Call Trace:[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334[ 33.028037][ T1896] ? strreplace+0xf2/0x110[ 33.028403][ T1896] ? strreplace+0xf2/0x110[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf[ 33.029283][ T1896] ? strreplace+0xf2/0x110[ 33.029666][ T1896] strreplace+0xf2/0x110[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0[ 33.033582][ T1896] brcmf_attach+0x246/0xd40[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50[ 33.034383][ T1896] ? kmemdup+0x30/0x40[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710[ 33.036315][ T1896] really_probe+0x1be/0xa90[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0[ 33.037383][ T1896] driver_probe_device+0x49/0x120[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120[ 33.042330][ T1896] __device_attach+0x207/0x330[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260[ 33.043914][ T1896] device_add+0xa61/0x1ce0[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90[ 33.046931][ T1896] usb_probe_device+0x9c/0x220[ 33.047434][ T1896] really_probe+0x1be/0xa90[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460[ 33.048134][ T1896] driver_probe_device+0x49/0x120[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_fq: fix integer overflow of "credit"if sch_fq is configured with "initial quantum" having values greater thanINT_MAX, the first assignment of "credit" does signed integer overflow toa very negative value.In this situation, the syzkaller script provided by Cristoph triggers theCPU soft-lockup warning even with few sockets. It's not an infinite loop,but "credit" wasn't probably meant to be minus 2Gb for each new flow.Capping "initial quantum" to INT_MAX proved to fix the issue.v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix wrong ct->timeout value(struct nf_conn)->timeout is an interval before the conntrackconfirmed. After confirmed, it becomes a timestamp.It is observed that timeout of an unconfirmed conntrack:- Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice.- Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted.Call Trace: dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsgSeparate the 2 cases in:- Setting `ct->timeout` in __nf_ct_set_timeout().- Getting `ct->timeout` in ctnetlink_dump_timeout().Pablo appends:Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag isset on, otherwise conntrack creation via ctnetlink breaks.Note that the problem described in this patch occurs since theintroduction of the nfnetlink_queue conntrack support, select asufficiently old Fixes: tag for -stable kernel to pick up this fix.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cdc_ncm: Deal with too low values of dwNtbOutMaxSizeCurrently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower thanthe calculated "min" value, but greater than zero, the logic setstx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB incdc_ncm_fill_tx_frame() where all the data is handled.For small values of dwNtbOutMaxSize the memory allocated duringalloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due tohow size is aligned at alloc time: size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));Thus we hit the same bug that we tried to squash withcommit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")Low values of dwNtbOutMaxSize do not cause an issue presently because atalloc_skb() time more memory (512b) is allocated than required for theSKB headers alone (320b), leaving some space (512b - 320b = 192b)for CDC data (172b).However, if more elements (for example 3 x u64 = [24b]) were added toone of the SKB header structs, say 'struct skb_shared_info',increasing its original size (320b [320b aligned]) to something larger(344b [384b aligned]), then suddenly the CDC data (172b) no longerfits in the spare SKB data area (512b - 384b = 128b).Consequently the SKB bounds checking semantics fails and panics:skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:------------[ cut here ]------------kernel BUG at net/core/skbuff.c:113!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023Workqueue: mld mld_ifc_workRIP: 0010:skb_panic net/core/skbuff.c:113 [inline]RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118[snip]Call Trace: skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100Deal with too low values of dwNtbOutMaxSize, clamp it in the range[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensureenough data space is allocated to handle CDC data by making suredwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to check readonly condition correctlyWith below case, it can mount multi-device image w/ rw option, howeverone of secondary device is set as ro, later update will cause panic, solet's introduce f2fs_dev_is_readonly(), and check multi-devices rw statusin f2fs_remount() w/ it in order to avoid such inconsistent mount status.mkfs.f2fs -c /dev/zram1 /dev/zram0 -fblockdev --setro /dev/zram1mount -t f2fs dev/zram0 /mnt/f2fsmount: /mnt/f2fs: WARNING: source write-protected, mounted read-only.mount -t f2fs -o remount,rw mnt/f2fsdd if=/dev/zero of=/mnt/f2fs/file bs=1M count=8192kernel BUG at fs/f2fs/inline.c:258!RIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs]Call Trace: f2fs_write_single_data_page+0x26b/0x9f0 [f2fs] f2fs_write_cache_pages+0x389/0xa60 [f2fs] __f2fs_write_data_pages+0x26b/0x2d0 [f2fs] f2fs_write_data_pages+0x2e/0x40 [f2fs] do_writepages+0xd3/0x1b0 __writeback_single_inode+0x5b/0x420 writeback_sb_inodes+0x236/0x5a0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x2a3/0x490 wb_do_writeback+0x2b2/0x330 wb_workfn+0x6a/0x260 process_one_work+0x270/0x5e0 worker_thread+0x52/0x3e0 kthread+0xf4/0x120 ret_from_fork+0x29/0x50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:m68k: Only force 030 bus error if PC not in exception table__get_kernel_nofault() does copy data in supervisor mode whenforcing a task backtrace log through /proc/sysrq_trigger.This is expected cause a bus error exception on e.g. NULLpointer dereferencing when logging a kernel task has noworkqueue associated. This bus error ought to be ignored.Our 030 bus error handler is ill equipped to deal with this:Whenever ssw indicates a kernel mode access on a data fault,we don't even attempt to handle the fault and instead alwayssend a SEGV signal (or panic). As a result, the checkfor exception handling at the fault PC (buried insend_sig_fault() which gets called from do_page_fault()eventually) is never used.In contrast, both 040 and 060 access error handlers do notcare whether a fault happened on supervisor mode access,and will call do_page_fault() on those, ultimately honoringthe exception table.Add a check in bus_error030 to call do_page_fault() in casewe do have an entry for the fault PC in our exception table.I had attempted a fix for this earlier in 2019 that did relyon testing pagefault_disabled() (see link below) to achievethe same thing, but this patch should be more generic.Tested on 030 Atari Falcon.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ebtables: fix table blob use-after-freeWe are not allowed to return an error at this point.Looking at the code it looks like ret is always 0 at thispoint, but its not.t = find_table_lock(net, repl->name, &ret, &ebt_mutex);... this can return a valid table, with ret != 0.This bug causes update of table->private with the newblob, but then frees the blob right away in the caller.Syzbot report:BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74Workqueue: netns cleanup_netCall Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613...ip(6)tables appears to be ok (ret should be 0 at this point) but makethis more obvious.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflowThis reverts commit443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync().This fixes a usage count underrun caused by doing a pm_runtime_put() eventhough pm_runtime_resume_and_get() returned an error.The three affected functions ignore -EACCES error from trying to getpm_runtime, and carry on, including a put at the end of the function.But pm_runtime_resume_and_get() does not increment the usage count if itreturns an error. So in the -EACCES case you must not callpm_runtime_put().The documentation for pm_runtime_get_sync() says: "Consider using pm_runtime_resume_and_get() ... as this is likely to result in cleaner code."In this case I don't think it results in cleaner code because thepm_runtime_put() at the end of the function would have to be conditional onthe return value from pm_runtime_resume_and_get() at the top of thefunction.pm_runtime_get_sync() doesn't have this problem because it alwaysincrements the count, so always needs a put. The code can just flow throughand do the pm_runtime_put() unconditionally.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:samples/bpf: Fix buffer overflow in tcp_baserttUsing sizeof(nv) or strlen(nv)+1 is correct.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:refscale: Fix uninitalized use of wait_queue_head_tRunning the refscale test occasionally crashes the kernel with thefollowing error:[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8[ 8569.952900] #PF: supervisor read access in kernel mode[ 8569.952902] #PF: error_code(0x0000) - not-present page[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 :[ 8569.952940] Call Trace:[ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale][ 8569.952959] kthread+0x10e/0x130[ 8569.952966] ret_from_fork+0x1f/0x30[ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call tothe torture_create_kthread() function that creates the ref_scale_readerkthread. Although this init_waitqueue_head() call will very likelycomplete before this kthread is created and starts running, it ispossible that the calling kthread will be delayed between the calls totorture_create_kthread() and init_waitqueue_head(). In this case, thenew kthread will use the waitqueue head before it is properly initialized,which is not good for the kernel's health and well-being.The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash hereThe offset of flags from list_head entry in wait_queue_entry is-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_taskstructure is zero initialized, the instruction will try to access address0xffffffffffffffe8, which is exactly the fault address listed above.This commit therefore invokes init_waitqueue_head() before creatingthe kthread.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: fix uninitialised kfifoIf a line is requested with debounce, and that results in debouncingin software, and the line is subsequently reconfigured to enable edgedetection then the allocation of the kfifo to contain edge events isoverlooked. This results in events being written to and read from anuninitialised kfifo. Read events are returned to userspace.Initialise the kfifo in the case where the software debounce isalready active.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check validity of link->type in bpf_link_show_fdinfo()If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessingbpf_link_type_strs[link->type] may result in an out-of-bounds access.To spot such missed invocations early in the future, checking thevalidity of link->type in bpf_link_show_fdinfo() and emitting a warningwhen such invocations are missed.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Fix uninitialized value issue in from_kuid and from_kgidocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid ina trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.Initialize all fields of newattrs to avoid uninitialized variables, bychecking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: Address an integer overflowDan Carpenter reports:> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data> structure") from Jun 22, 2020 (linux-next), leads to the following> Smatch static checker warning:>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)> 489 {> 490 u32 segcount;> 491 __be32 *p;> 492> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))> ^^^^^^^^>> 494 return false;> 495> 496 /* A bogus segcount causes this buffer overflow check to fail. */> 497 p = xdr_inline_decode(&rctxt->rc_stream,> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));>>> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will> have an integer overflow and some those values will be accepted by> xdr_inline_decode().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()This loop is supposed to break if the frequency returned fromclk_round_rate() is the same as on the previous iteration. However,that check doesn't make sense on the first iteration through the loop.It leads to reading before the start of these->clk_perf_tbl[] array.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/bluefield: Fix potential integer overflowThe 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idxleft-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as32-bits wide the left-shift operation truncates the upper 16 bits ofinformation during the calculation of the SMC argument.The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent anypotential integer overflow, i.e. loss of data from upper 16 bits.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: Fix double free issue with interrupt buffer allocationIn lan78xx_probe(), the buffer `buf` was being freed twice: onceimplicitly through `usb_free_urb(dev->urb_intr)` with the`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This causeda double free issue.To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls tosimplify the initialization sequence and removed the redundant`kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuringit is correctly managed by `usb_fill_int_urb()` and freed by`usb_free_urb()` as intended.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor modeath11k_hal_srng_* should be used with srng->lock to protect srng data.For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),they use ath11k_hal_srng_* for many times but never call srng->lock.So when running (full) monitor mode, warning will occur:RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319So add srng->lock for them to avoid such warnings.Inorder to fetch the srng->lock, should change srng's definition from'void' to 'struct hal_srng'. And initialize them elsewhere to preventone line of code from being too long. This is consistent with other ringprocess functions, such as ath11k_dp_process_rx().Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A vulnerability has been found in GNU Binutils 2.45. This impacts the function bfd_elf_gc_record_vtentry of the file bfd/elflink.c of the component Linker. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier of the patch is 047435dd988a3975d40c6626a8f739a0b2e154bc. To fix this issue, it is recommended to deploy a patch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libblkid1 > 0-0 (version in image is 2.37.4-150500.9.17.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when attempting to join an aborted transactionWhen we are trying to join the current transaction and if it's aborted,we read its 'aborted' field after unlocking fs_info->trans_lock andwithout holding any extra reference count on it. This means that aconcurrent task that is aborting the transaction may free the transactionbefore we read its 'aborted' field, leading to a use-after-free.Fix this by reading the 'aborted' field while holding fs_info->trans_locksince any freeing task must first acquire that lock and setfs_info->running_transaction to NULL before freeing the transaction.This was reported by syzbot and Dmitry with the following stack tracesfrom KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 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 Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: Fix KMSAN uninit-value warning with bpfSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by theppp driver not initializing a 2-byte header when using socket filter.The following code can generate a PPP filter BPF program:'''struct bpf_program fp;pcap_t *handle;handle = pcap_open_dead(DLT_PPP_PPPD, 65535);pcap_compile(handle, &fp, "ip and outbound", 0, 0);bpf_dump(&fp, 1);'''Its output is:'''(000) ldh [2](001) jeq #0x21 jt 2 jf 5(002) ldb [0](003) jeq #0x1 jt 4 jf 5(004) ret #65535(005) ret #0'''Wen can find similar code at the following link:https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680The maintainer of this code repository is also the original maintainerof the ppp driver.As you can see the BPF program skips 2 bytes of data and then reads the'Protocol' field to determine if it's an IP packet. Then it read the firstbyte of the first 2 bytes to determine the direction.The issue is that only the first byte indicating direction is initializedin current ppp driver code while the second byte is not initialized.For normal BPF programs generated by libpcap, uninitialized data won't beused, so it's not a problem. However, for carefully crafted BPF programs,such as those generated by syzkaller [2], which start reading from offset0, the uninitialized data will be used and caught by KMSAN.[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing closetimeo mount optionUser-provided mount parameter closetimeo of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the 'function_graph' tracer to the'timerlat' tracer, s_start only calls graph_trace_close of the'function_graph' tracer to free 'iter->private', but does not setit to NULL. This provides an opportunity for 'event->funcs->trace()'to use an invalid 'iter->private'.To fix this issue, set 'iter->private' to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary'iter->private = NULL' during each 'cat trace' when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Don't expose hw_counters outside of init net namespaceCommit 467f432a521a ("RDMA/core: Split port and device counter sysfsattributes") accidentally almost exposed hw counters to non-init netnamespaces. It didn't expose them fully, as an attempt to read any ofthose counters leads to a crash like this one:[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028[42021.814463] #PF: supervisor read access in kernel mode[42021.819549] #PF: error_code(0x0000) - not-present page[42021.824636] PGD 0 P4D 0[42021.827145] Oops: 0000 [#1] SMP PTI[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX[42021.841697] Hardware name: XXX[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core][42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[42021.949324] Call Trace:[42021.951756] [42021.953842] [] ? show_regs+0x64/0x70[42021.959030] [] ? __die+0x78/0xc0[42021.963874] [] ? page_fault_oops+0x2b5/0x3b0[42021.969749] [] ? exc_page_fault+0x1a2/0x3c0[42021.975549] [] ? asm_exc_page_fault+0x26/0x30[42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core][42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core][42021.995438] [] dev_attr_show+0x1e/0x50[42022.000803] [] sysfs_kf_seq_show+0x81/0xe0[42022.006508] [] seq_read_iter+0xf4/0x410[42022.011954] [] vfs_read+0x16e/0x2f0[42022.017058] [] ksys_read+0x6e/0xe0[42022.022073] [] do_syscall_64+0x6a/0xa0[42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*The panic occurs because of casting the device pointer into anib_device pointer using container_of() in hw_stat_device_show() iswrong and leads to a memory corruption.However the real problem is that hw counters should never been exposedoutside of the non-init net namespace.Fix this by saving the index of the corresponding attribute group(it might be 1 or 2 depending on the presence of driver-specificattributes) and zeroing the pointer to hw_counters group for compatdevices during the initialization.With this fix applied hw_counters are not available in a non-initnet namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[pabeni@redhat.com: fixed subj typo]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: do not leak refcount in reorder_workA recent patch that addressed a UAF introduced a reference count leak:the parallel_data refcount is incremented unconditionally, regardlessof the return value of queue_work(). If the work item is already queued,the incremented refcount is never decremented.Fix this by checking the return value of queue_work() and decrementingthe refcount when necessary.Resolves:Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lzo - Fix compression buffer overrunUnlike the decompression code, the compression code in LZO neverchecked for output overruns. It instead assumes that the calleralways provides enough buffer space, disregarding the buffer lengthprovided by the caller.Add a safe compression interface that checks for the end of bufferbefore each write. Use the safe interface in crypto/lzo.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hisi_acc_vfio_pci: fix XQE dma address errorThe dma addresses of EQE and AEQE are wrong after migration andresults in guest kernel-mode encryption services failure.Comparing the definition of hardware registers, we found thatthere was an error when the data read from the register wascombined into an address. Therefore, the address combinationsequence needs to be corrected.Even after fixing the above problem, we still have an issuewhere the Guest from an old kernel can get migrated tonew kernel and may result in wrong data.In order to ensure that the address is correct after migration,if an old magic number is detected, the dma address needs to beupdated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: clear the dst when changing skb protocolA not-so-careful NAT46 BPF program can crash the kernelif it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10)The output interface has a 4->6 program attached at ingress.We try to loop the multicast skb back to the sending socket.Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdrand changes skb->protocol to v6. We enter ip6_rcv_core whichtries to use skb_dst(). But the dst is still an IPv4 one leftafter IPv4 mcast output.Clear the dst in all BPF helpers which change the protocol.Try to preserve metadata dsts, those may carry non-routingmetadata.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: reject invalid perturb periodGerrard Tai reported that SFQ perturb_period has no range check yet,and this can be used to trigger a race condition fixed in a separate patch.We want to make sure ctl->perturb_period * HZ will not overflowand is positive.tc qd add dev lo root sfq perturb -10 # negative value : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 1000000000 # too big : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 2000000 # acceptable valuetc -s -d qd sh dev loqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell_rbu: Fix list usagePass the correct list head to list_for_each_entry*() when looping throughthe packet list.Without this patch, reading the packet data via sysfs will show the dataincorrectly (because it starts at the wrong packet), and clearing thepacket list will result in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix use-after-free of work objects after cm_id destructionThe commit 59c68ac31e15 ("iw_cm: free cm_id resources on the lastderef") simplified cm_id resource management by freeing cm_id once allreferences to the cm_id were removed. The references are removed eitherupon completion of iw_cm event handlers or when the application destroysthe cm_id. This commit introduced the use-after-free condition wherecm_id_private object could still be in use by event handler works duringthe destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix ause-after-free related to destroying CM IDs") addressed this use-after-free by flushing all pending works at the cm_id destruction.However, still another use-after-free possibility remained. It happenswith the work objects allocated for each cm_id_priv withinalloc_work_entries() during cm_id creation, and subsequently freed indealloc_work_entries() once all references to the cm_id are removed.If the cm_id's last reference is decremented in the event handler work,the work object for the work itself gets removed, and causes the use-after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30This BUG is reproducible by repeating the blktests test case nvme/061for the rdma transport and the siw driver.To avoid the use-after-free of cm_id_private work objects, ensure thatthe last reference to the cm_id is decremented not in the event handlerworks, but in the cm_id destruction context. For that purpose, mo---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: inline: fix len overflow in ext4_prepare_inline_dataWhen running the following code on an ext4 filesystem with inline_datafeature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL);That happens because write_begin will succeed as whenext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + lenwill be truncated, leading to ext4_prepare_inline_data parameter to be 6instead of 0x10000000006.Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);at ext4_write_inline_data.Fix it by using a loff_t type for the len parameter inext4_prepare_inline_data instead of an unsigned int.[ 44.545164] ------------[ cut here ]------------[ 44.545530] kernel BUG at fs/ext4/inline.c:240![ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0[ 44.546523] PKRU: 55555554[ 44.546523] Call Trace:[ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0[ 44.546523] generic_perform_write+0x17e/0x270[ 44.546523] ext4_buffered_write_iter+0xc8/0x170[ 44.546523] vfs_write+0x2be/0x3e0[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0[ 44.546523] do_syscall_64+0x6a/0xf0[ 44.546523] ? __wake_up+0x89/0xb0[ 44.546523] ? xas_find+0x72/0x1c0[ 44.546523] ? next_uptodate_folio+0x317/0x330[ 44.546523] ? set_pte_range+0x1a6/0x270[ 44.546523] ? filemap_map_pages+0x6ee/0x840[ 44.546523] ? ext4_setattr+0x2fa/0x750[ 44.546523] ? do_pte_missing+0x128/0xf70[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0[ 44.546523] ? ___pte_offset_map+0x19/0x100[ 44.546523] ? handle_mm_fault+0x721/0xa10[ 44.546523] ? do_user_addr_fault+0x197/0x730[ 44.546523] ? do_syscall_64+0x76/0xf0[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 44.546523] RIP: 0033:0x7f42999c6687[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix invalid node indexOn a system with DRAM interleave enabled, out-of-bound access isdetected:megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0------------[ cut here ]------------UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28index -1 is out of range for type 'cpumask *[1024]'dump_stack_lvl+0x5d/0x80ubsan_epilogue+0x5/0x2b__ubsan_handle_out_of_bounds.cold+0x46/0x4bmegasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas]megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas]local_pci_probe+0x42/0x90pci_device_probe+0xdc/0x290really_probe+0xdb/0x340__driver_probe_device+0x78/0x110driver_probe_device+0x1f/0xa0__driver_attach+0xba/0x1c0bus_for_each_dev+0x8b/0xe0bus_add_driver+0x142/0x220driver_register+0x72/0xd0megasas_init+0xdf/0xff0 [megaraid_sas]do_one_initcall+0x57/0x310do_init_module+0x90/0x250init_module_from_file+0x85/0xc0idempotent_init_module+0x114/0x310__x64_sys_finit_module+0x65/0xc0do_syscall_64+0x82/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eFix it accordingly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()In snd_usb_get_audioformat_uac3(), the length value returned fromsnd_usb_ctl_msg() is used directly for memory allocation withoutvalidation. This length is controlled by the USB device.The allocated buffer is cast to a uac3_cluster_header_descriptorand its fields are accessed without verifying that the bufferis large enough. If the device returns a smaller than expectedlength, this leads to an out-of-bounds read.Add a length check to ensure the buffer is large enough foruac3_cluster_header_descriptor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: eir: Fix possible crashes on eir_create_adv_dataeir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWERwithout checking if that would fit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:seg6: Fix validation of nexthop addressesThe kernel currently validates that the length of the provided nexthopaddress does not exceed the specified length. This can lead to thekernel reading uninitialized memory if user space provided a shorterlength than the specified one.Fix by validating that the provided length exactly matches the specifiedone.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Prevent attempts to reclaim poisoned pagesTL;DR: SGX page reclaim touches the page to copy its contents tosecondary storage. SGX instructions do not gracefully handle machinechecks. Despite this, the existing SGX code will try to reclaim pagesthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.The longer story:Pages used by an enclave only get epc_page->poison set inarch_memory_failure() but they currently stay on sgx_active_page_list untilsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.epc_page->poison is not checked in the reclaimer logic meaning that, if otherconditions are met, an attempt will be made to reclaim an EPC page that waspoisoned. This is bad because 1. we don't want that page to end up addedto another enclave and 2. it is likely to cause one core to shut downand the kernel to panic.Specifically, reclaiming uses microcode operations including "EWB" whichaccesses the EPC page contents to encrypt and write them out to non-SGXmemory. Those operations cannot handle MCEs in their accesses other thanby putting the executing core into a special shutdown state (affectingboth threads with HT.) The kernel will subsequently panic on theremaining cores seeing the core didn't enter MCE handler(s) in time.Call sgx_unmark_page_reclaimable() to remove the affected EPC page fromsgx_active_page_list on memory error to stop it being considered forreclaiming.Testing epc_page->poison in sgx_reclaim_pages() would also work but I assumeit's better to add code in the less likely paths.The affected EPC page is not added to &node->sgx_poison_page_list untillater in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd.Membership on other lists doesn't change to avoid changing any of thelists' semantics except for sgx_active_page_list. There's a "TBD" commentin arch_memory_failure() about pre-emptive actions, the goal here is notto address everything that it may imply.This also doesn't completely close the time window when a memory errornotification will be fatal (for a not previously poisoned EPC page) --the MCE can happen after sgx_reclaim_pages() has selected its candidatesor even *inside* a microcode operation (actually easy to trigger due tothe amount of time spent in them.)The spinlock in sgx_unmark_page_reclaimable() is safe becausememory_failure() runs in process context and no spinlocks are held,explicitly noted in a mm/memory-failure.c comment.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/vmci: Clear the vmci transport packet properly when initializing itIn vmci_transport_packet_init memset the vmci_transport_packet beforepopulating the fields to avoid any uninitialised data being left in thestructure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: check msg length in SMBUS block readFor SMBUS block read, do not continue to read if the message lengthpassed from the device is '0' or greater than the maximum allowed bytes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix uaf in nbd_genl_connect() error pathThere is a use-after-free issue in nbd:block nbd6: Receive control failed (result -104)block nbd6: shutting down sockets==================================================================BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: nbd6-recv recv_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() does not properly stop the device on certainerror paths after nbd_start_device() has been called. This causesthe error path to put nbd->config while recv_work continue to usethe config after putting it, leading to use-after-free in recv_work.This patch moves nbd_start_device() after the backend file creation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: aio_iiro_16: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl812: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: common: st_sensors: Fix use of uninitialize device structsThroughout the various probe functions &indio_dev->dev is used before itis initialized. This caused a kernel panic in st_sensors_power_enable()when the call to devm_regulator_bulk_get_enable() fails and then callsdev_err_probe() with the uninitialized device.This seems to only cause a panic with dev_err_probe(), dev_err(),dev_warn() and dev_info() don't seem to cause a panic, but are fixedas well.The issue is reported and traced here: [1]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer deference in try_to_register_cardIn try_to_register_card(), the return value of usb_ifnum_to_if() ispassed directly to usb_interface_claimed() without a NULL check, whichwill lead to a NULL pointer dereference when creating an invalidUSB audio device. Fix this by adding a check to ensure the interfacepointer is valid before passing it to usb_interface_claimed().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: guard against EA inode refcount underflow in xattr updatesyzkaller found a path where ext4_xattr_inode_update_ref() reads an EAinode refcount that is already <= 0 and then applies ref_change (often-1). That lets the refcount underflow and we proceed with a bogus value,triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117Make the invariant explicit: if the current refcount is non-positive,treat this as on-disk corruption, emit ext4_error_inode(), and fail theoperation with -EFSCORRUPTED instead of updating the refcount. Delete theWARN_ONCE() as negative refcounts are now impossible; keep error reportingin ext4_error_inode().This prevents the underflow and the follow-on orphan/cleanup churn.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadgetIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadgetstructure (pdev->gadget) was freed before its endpoints.The endpoints are linked via the ep_list in the gadget structure.Freeing the gadget first leaves dangling pointers in the endpoint list.When the endpoints are subsequently freed, this results in a use-after-free.Fix:By separating the usb_del_gadget_udc() operation into distinct "del" and"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to thefinal release of the gadget structure with usb_put_gadget().A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattrCurrently when both IMA and EVM are in fix mode, the IMA signature willbe reset to IMA hash if a program first stores IMA signature insecurity.ima and then writes/removes some other security xattr for thefile.For example, on Fedora, after booting the kernel with "ima_appraise=fixevm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,installing/reinstalling a package will not make good reference IMAsignature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404...This happens because when setting security.selinux, the IMA_DIGSIG flagthat had been set early was cleared. As a result, IMA hash is generatedwhen the file is closed.Similarly, IMA signature can be cleared on file close after removingsecurity xattr like security.evm or setting/removing ACL.Prevent replacing the IMA file signature with a file hash, by preventingthe IMA_DIGSIG flag from being reset.Here's a minimal C reproducer which sets security.selinux as the laststep which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; }
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: stratix10-svc: fix bug in saving controller dataFix the incorrect usage of platform_set_drvdata and dev_set_drvdata. Theyboth are of the same data and overrides each other. This resulted in thermmod of the svc driver to fail and throw a kernel panic for kthread_stopand fifo free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led-bl: Add devlink to supplier LEDsLED Backlight is a consumer of one or multiple LED class devices, butdevlink is currently unable to create correct supplier-producer links whenthe supplier is a class device. It creates instead a link where thesupplier is the parent of the expected device.One consequence is that removal order is not correctly enforced.Issues happen for example with the following sections in a device treeoverlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; };In this example, the devlink should be created between the backlight-addon(consumer) and the pca9632@62 (supplier). Instead it is created between thebacklight-addon (consumer) and the parent of the pca9632@62, which istypically the I2C bus adapter.On removal of the above overlay, the LED driver can be removed before thebacklight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98Another way to reproduce the bug without any device tree overlays isunbinding the LED class device (pca9632@62) before unbinding the consumer(backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbindFix by adding a devlink between the consuming led-backlight device and thesupplying LED device, as other drivers and subsystems do as well.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:via_wdt: fix critical boot hang due to unnamed resource allocationThe VIA watchdog driver uses allocate_resource() to reserve a MMIOregion for the watchdog control register. However, the allocatedresource was not given a name, which causes the kernel resource treeto contain an entry marked as "" under /proc/iomem on x86platforms.During boot, this unnamed resource can lead to a critical hang becausesubsequent resource lookups and conflict checks fail to handle theinvalid entry properly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:net: sock: fix hardened usercopy panic in sock_recv_errqueueskbuff_fclone_cache was created without defining a usercopy region,[1] unlike skbuff_head_cache which properly whitelists the cb[] field.[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY isenabled and the kernel attempts to copy sk_buff.cb data to userspacevia sock_recv_errqueue() -> put_cmsg().The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1]2. The skb is cloned via skb_clone() using the pre-allocated fclone[3] 3. The cloned skb is queued to sk_error_queue for timestampreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5]When cloned skbs allocated from skbuff_fclone_cache are used in thesocket error queue, accessing the sock_exterr_skb structure in skb->cbvia put_cmsg() triggers a usercopy hardening violation:[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)![ 5.382796] kernel BUG at mm/usercopy.c:102![ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI[ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7[ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80[ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490[ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246[ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74[ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0[ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74[ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001[ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00[ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000[ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0[ 5.384903] PKRU: 55555554[ 5.384903] Call Trace:[ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0[ 5.384903] __check_object_size+0x46c/0x690[ 5.384903] put_cmsg+0x129/0x5e0[ 5.384903] sock_recv_errqueue+0x22f/0x380[ 5.384903] tls_sw_recvmsg+0x7ed/0x1960[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? schedule+0x6d/0x270[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? mutex_unlock+0x81/0xd0[ 5.384903] ? __pfx_mutex_unlock+0x10/0x10[ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10[ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0[ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix reference state management for synchronous callbacksCurrently, verifier verifies callback functions (sync and async) as ifthey will be executed once, (i.e. it explores execution state as if thefunction was being called once). The next insn to explore is set tostart of subprog and the exit from nested frame is handled usingcurframe > 0 and prepare_func_exit. In case of async callback it uses acustomized variant of push_stack simulating a kind of branch to set upcustom state and execution context for the async callback.While this approach is simple and works when callback really will beexecuted only once, it is unsafe for all of our current helpers whichare for_each style, i.e. they execute the callback multiple times.A callback releasing acquired references of the caller may do somultiple times, but currently verifier sees it as one call inside theframe, which then returns to caller. Hence, it thinks it released somereference that the cb e.g. got access through callback_ctx (registerfilled inside cb from spilled typed register on stack).Similarly, it may see that an acquire call is unpaired inside thecallback, so the caller will copy the reference state of callback andthen will have to release the register with new ref_obj_ids. But again,the callback may execute multiple times, but the verifier will onlyaccount for acquired references for a single symbolic execution of thecallback, which will cause leaks.Note that for async callback case, things are different. While currentlywe have bpf_timer_set_callback which only executes it once, even formultiple executions it would be safe, as reference state is NULL andcheck_reference_leak would force program to release state beforeBPF_EXIT. The state is also unaffected by analysis for the caller frame.Hence async callback is safe.Since we want the reference state to be accessible, e.g. for pointersloaded from stack through callback_ctx's PTR_TO_STACK, we still have tocopy caller's reference_state to callback's bpf_func_state, but weenforce that whatever references it adds to that reference_state hasbeen released before it hits BPF_EXIT. This requires introducing a newcallback_ref member in the reference state to distinguish between callervs callee references. Hence, check_reference_leak now errors out if itsees we are in callback_fn and we have not released callback_ref refs.Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2etc. we need to also distinguish between whether this particular refbelongs to this callback frame or parent, and only error for our own, sowe store state->frameno (which is always non-zero for callbacks).In short, callbacks can read parent reference_state, but cannot mutateit, to be able to use pointers acquired by the caller. They must onlyundo their changes (by releasing their own acquired_refs beforeBPF_EXIT) on top of caller reference_state before returning (at whichpoint the caller and callback state will match anyway, so no need tocopy it back to caller).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix multiple LUN_RESET handlingThis fixes a bug where an initiator thinks a LUN_RESET has cleaned uprunning commands when it hasn't. The bug was added in commit 51ec502a3266("target: Delete tmr from list before processing").The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already.Fix the bug by reverting the patch, and serialize the execution ofLUN_RESETs and Preempt and Aborts.Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,because it turns out the original patch fixed a bug that was notmentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a secondLUN_RESET and wait on it. Then the second reset will runcore_tmr_drain_tmr_list and see the first reset and wait on it resulting ina deadlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: Avoid list corruption when removing a slab from the full listBoot with slub_debug=UFPZ.If allocated object failed in alloc_consistency_checks, all objects ofthe slab will be marked as used, and then the slab will be removed fromthe partial list.When an object belonging to the slab got freed later, the remove_full()function is called. Because the slab is neither on the partial list noron the full list, it eventually lead to a list corruption (actually alist poison being detected).So we need to mark and isolate the slab page with metadata corruption,do not put it back in circulation.Because the debug caches avoid all the fastpaths, reusing the frozen bitto mark slab page with metadata corruption seems to be fine.[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100)[ 4277.387023] ------------[ cut here ]------------[ 4277.387880] kernel BUG at lib/list_debug.c:56![ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs][ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4277.410000] PKRU: 55555554[ 4277.410645] Call Trace:[ 4277.411234] [ 4277.411777] ? die+0x32/0x80[ 4277.412439] ? do_trap+0xd6/0x100[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.414158] ? do_error_trap+0x6a/0x90[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.415915] ? exc_invalid_op+0x4c/0x60[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.420410] free_to_partial_list+0x515/0x5e0[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs][ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs][ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs][ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs][ 4277.428567] xfs_inactive+0x22d/0x290 [xfs][ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.430479] process_one_work+0x171/0x340[ 4277.431227] worker_thread+0x277/0x390[ 4277.431962] ? __pfx_worker_thread+0x10/0x10[ 4277.432752] kthread+0xf0/0x120[ 4277.433382] ? __pfx_kthread+0x10/0x10[ 4277.434134] ret_from_fork+0x2d/0x50[ 4277.434837] ? __pfx_kthread+0x10/0x10[ 4277.435566] ret_from_fork_asm+0x1b/0x30[ 4277.436280]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rtosyzbot reported a possible shift-out-of-bounds [1]Blamed commit added rto_alpha_max and rto_beta_max set to 1000.It is unclear if some sctp users are setting very large rto_alphaand/or rto_beta.In order to prevent user regression, perform the test at run time.Also add READ_ONCE() annotations as sysctl values can change under us.[1]UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41shift exponent 64 is too large for 32-bit type 'unsigned int'CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- screen > 0-0 (version in image is 4.6.2-150000.5.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: account for current allocated stack depth in widen_imprecise_scalars()The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);Where prev_st is an ancestor of the queued_st in the explored statestree. This ancestor is not guaranteed to have same allocated stackdepth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loopHere, for a second 'foo' call prev_st->allocated_stack is 128,while queued_st->allocated_stack is much smaller.widen_imprecise_scalars() needs to take this into account and avoidaccessing bpf_verifier_state->frame[*]->stack out of bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid buffer leaks on xdp_do_redirect() failureBefore enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each softwareBD in the RX ring between index orig_i and i can have one of 2 refcountvalues on its page.We are the owner of the current buffer that is being processed, so therefcount will be at least 1.If the current owner of the buffer at the diametrically opposed indexin the RX ring (i.o.w, the other half of this page) has not yet calledkfree(), this page's refcount could even be 2.enetc_page_reusable() in enetc_flip_rx_buff() tests for the pagerefcount against 1, and [ if it's 2 ] does not attempt to reuse it.But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,the page refcount can have one of 3 values. It can also be 0, if thereis no owner of the other page half, and xdp_do_redirect() for thisbuffer ran so far that it triggered a flush of the devmap/cpumap bulkqueue, and the consumers of those bulk queues also freed the buffer,all by the time xdp_do_redirect() returns the execution back to enetc.This is the reason why enetc_flip_rx_buff() is called beforexdp_do_redirect(), but there is a big flaw with that reasoning:enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of theenetc_page_reusable() branch, and if xdp_do_redirect() returns an error,we call enetc_xdp_free(), which does not deal gracefully with that.In fact, what happens is quite special. The page refcounts start as 1.enetc_flip_rx_buff() figures they're reusable, transfers theserx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), andbumps the refcount to 2. When xdp_do_redirect() later returns an error,we call the no-op enetc_xdp_free(), but we still haven't lost thereference to that page. A copy of it is still at rx_ring->next_to_alloc,but that has refcount 2 (and there are no concurrent owners of it inflight, to drop the refcount). What really kills the system is whenwe'll flip the rx_swbd->page the second time around. With an updatedrefcount of 2, the page will not be reusable and we'll really leak it.Then enetc_new_page() will have to allocate more pages, which will theneventually leak again on further errors from xdp_do_redirect().The problem, summarized, is that we zeroize rx_swbd->page before we'recompletely done with it, and this makes it impossible for the error pathto do something with it.Since the packet is potentially multi-buffer and therefore therx_swbd->page is potentially an array, manual passing of the oldpointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bitdifficult.For the sake of going with a simple solution, we accept the possibilityof racing with xdp_do_redirect(), and we move the flip procedure toexecute only on the redirect success path. By racing, I mean that thepage may be deemed as not reusable by enetc (having a refcount of 0),but there will be no leak in that case, either.Once we accept that, we have something better to do with buffers onXDP_REDIRECT failure. Since we haven't performed half-page flipping yet,we won't, either (and this way, we can avoid enetc_xdp_free()completely, which gives the entire page to the slab allocator).Instead, we'll call enetc_xdp_drop(), which will recycle this half ofthe buffer back to the RX ring.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Update ipcomp_scratches with NULL when freedCurrently if ipcomp_alloc_scratches() fails to allocate memoryipcomp_scratches holds obsolete address. So when we try to free thepercpu scratches using ipcomp_free_scratches() it tries to vfree nonexistent vm area. Described below:static void * __percpu *ipcomp_alloc_scratches(void){ ... scratches = alloc_percpu(void *); if (!scratches) return NULL;ipcomp_scratches does not know about this allocation failure.Therefore holding the old obsolete address. ...}So when we free,static void ipcomp_free_scratches(void){ ... scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));Trying to free non existent page, causing warning: trying to vfreeexistent vm area. ...}Fix this breakage by updating ipcomp_scrtches with NULL when scratchesis freed
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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.5 (version in image is 15.5-150500.43.2).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3-requests > 0-0 (version in image is 2.25.1-150300.3.18.1).
-
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 (&#x...;). 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:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.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:ipv6: Fix soft lockups in fib6_select_path under high next hop churnSoft lockups have been observed on a cluster of Linux-based edge routerslocated in a highly dynamic environment. Using the `bird` service, theserouters continuously update BGP-advertised routes due to frequentlychanging nexthop destinations, while also managing significant IPv6traffic. The lockups occur during the traversal of the multipathcircular linked-list in the `fib6_select_path` function, particularlywhile iterating through the siblings in the list. The issue typicallyarises when the nodes of the linked list are unexpectedly deletedconcurrently on a different core-indicated by their 'next' and'previous' elements pointing back to the node itself and their referencecount dropping to zero. This results in an infinite loop, leading to asoft lockup that triggers a system panic via the watchdog timer.Apply RCU primitives in the problematic code sections to resolve theissue. Where necessary, update the references to fib6_siblings toannotate or use the RCU APIs.Include a test script that reproduces the issue. The scriptperiodically updates the routing table while generating a heavy loadof outgoing IPv6 traffic through multiple iperf3 clients. Itconsistently induces infinite soft lockups within a couple of minutes.Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d-- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b512 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f4713 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d014 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd9627415 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd9647416 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd9661517 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b319 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b920 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc1800024 [ffffbd13003d3db8] net_rx_action at ffffffff8dc1858125 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e926 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe4727 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a3028 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa6430 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: protect link down work from execute after lgr freedlink down work may be scheduled before lgr freed but executeafter lgr freed, which may result in crash. So it is need tohold a reference before shedule link down work, and put thereference after work executed or canceled.The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbagecollection confirm race"), `cpu` and `jiffies32` were introduced tothe struct nf_conncount_tuple.The commit made nf_conncount_add() initialize `conn->cpu` and`conn->jiffies32` when allocating the struct.In contrast, count_tree() was not changed to initialize them.By commit 34848d5c896e ("netfilter: nf_conncount: Split insert andtraversal"), count_tree() was split and the relevant allocationcode now resides in insert_tree().Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 socketsWhen calling netlbl_conn_setattr(), addr->sa_family is usedto determine the function behavior. If sk is an IPv4 socket,but the connect function is called with an IPv6 address,the function calipso_sock_setattr() is triggered.Inside this function, the following code is executed:sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;Since sk is an IPv4 socket, pinet6 is NULL, leading to anull pointer dereference.This patch fixes the issue by checking if inet6_sk(sk)returns a NULL pointer before accessing pinet6.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- krb5 > 0-0 (version in image is 1.20.1-150500.3.17.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: don't restore null sk_state_changequeue->state_change is set as part of nvmet_tcp_set_queue_sock(), but ifthe TCP connection isn't established when nvmet_tcp_set_queue_sock() iscalled then queue->state_change isn't set and sock->sk->sk_state_changeisn't replaced.As such we don't need to restore sock->sk->sk_state_change ifqueue->state_change is NULL.This avoids NULL pointer dereferences such as this:[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 286.467147][ C0] RIP: 0010:0x0[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400[ 286.475453][ C0] Call Trace:[ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60[ 286.478174][ C0] ? __build_skb_around+0x234/0x330[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30[ 286.482769][ C0] ? ktime_get+0x66/0x150[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10[ 286.486917][ C0] ? lock_release+0x217/0x2c0[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack][ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420[ 286.494268][ C0] ip_local_deliver+0x168/0x430[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20[ 286.496806][ C0] ? lock_release+0x217/0x2c0[ 286.497414][ C0] ip_rcv+0x455/0x6e0[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10[ ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Duplicate SPI HandlingThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPINetlink message, which triggers the kernel function xfrm_alloc_spi().This function is expected to ensure uniqueness of the Security ParameterIndex (SPI) for inbound Security Associations (SAs). However, it canreturn success even when the requested SPI is already in use, leadingto duplicate SPIs assigned to multiple inbound SAs, differentiatedonly by their destination addresses.This behavior causes inconsistencies during SPI lookups for inbound packets.Since the lookup may return an arbitrary SA among those with the same SPI,packet processing can fail, resulting in packet drops.According to RFC 4301 section 4.4.2 , for inbound processing a unicast SAis uniquely identified by the SPI and optionally protocol.Reproducing the Issue Reliably:To consistently reproduce the problem, restrict the available SPI range incharon.conf : spi_min = 0x10000000 spi_max = 0x10000002This limits the system to only 2 usable SPI values.Next, create more than 2 Child SA. each using unique pair of src/dst address.As soon as the 3rd Child SA is initiated, it will be assigned a duplicateSPI, since the SPI pool is already exhausted.With a narrow SPI range, the issue is consistently reproducible.With a broader/default range, it becomes rare and unpredictable.Current implementation:xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.So if two SAs have the same SPI but different destination addresses, thenthey will:a. Hash into different bucketsb. Be stored in different linked lists (byspi + h)c. Not be seen in the same hlist_for_each_entry_rcu() iteration.As a result, the lookup will result in NULL and kernel allows that Duplicate SPIProposed Change:xfrm_state_lookup_spi_proto() does a truly global search - across all states,regardless of hash bucket and matches SPI and proto.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: Any project that uses Protobuf Pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of recursive groups, recursive messages or a series of SGROUP tags can be corrupted by exceeding the Python recursion limit. This can result in a Denial of service by crashing the application with a RecursionError. We recommend upgrading to version =>6.31.1 or beyond commit 17838beda2943d08b8a9d4df5b68f5f04f26d901
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311-protobuf > 0-0 (version in image is 4.25.1-150500.12.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet: frags: flush pending skbs in fqdir_pre_exit()We have been seeing occasional deadlocks on pernet_ops_rwsem sinceSeptember in NIPA. The stuck task was usually modprobe (often loadinga driver like ipvlan), trying to take the lock as a Writer.lockdep does not track readers for rwsems so the read wasn't obviousfrom the reports.On closer inspection the Reader holding the lock was conntrack loopingforever in nf_conntrack_cleanup_net_list(). Based on past experiencewith occasional NIPA crashes I looked thru the tests which run beforethe crash and noticed that the crash follows ip_defrag.sh. An immediatered flag. Scouring thru (de)fragmentation queues reveals skbs sittingaround, holding conntrack references.The problem is that since conntrack depends on nf_defrag_ipv6,nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first itsnetns exit hooks run _after_ conntrack's netns exit hook.Flush all fragment queue SKBs during fqdir_pre_exit() to releaseconntrack references before conntrack cleanup runs. Also flushthe queues in timer expiry handlers when they discover fqdir->deadis set, in case packet sneaks in while we're running the pre_exitflush.The commit under Fixes is not exactly the culprit, but I thinkpreviously the timer firing would eventually unblock the spinningconntrack.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix UAF of ref->proc caused by race conditionA transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment thereference for a node. In this case, the target proc normally releasesthe failed reference upon close as expected. However, if the target isdying in parallel the call will race with binder_deferred_release(), sothe target could have released all of its references by now leaving thecleanup of the new failed reference unhandled.The transaction then ends and the target proc gets released making theref->proc now a dangling pointer. Later on, ref->node is closed and weattempt to take spin_lock(&ref->proc->inner_lock), which leads to theuse-after-free bug reported below. Let's fix this by cleaning up thefailed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: fix shift-out-of-bounds in check_special_flagsUBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1Since the type of Node's flags is unsigned long, we should define thesemacros with same type too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix UAF in run_timer_softirq()When dm_resume() and dm_destroy() are concurrent, it willlead to UAF, as follows: BUG: KASAN: use-after-free in __run_timers+0x173/0x710 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 Call Trace: dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+0x16e/0x62c __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0One of the concurrency UAF can be shown as below: use freedo_resume | __find_device_hash_cell | dm_get | atomic_inc(&md->holders) | | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | atomic_read(&md->holders) | msleep(1) dm_resume | __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add delay work | dm_put | atomic_dec(&md->holders) | | dm_table_destroy | pool_dtr | __pool_dec | __pool_destroy | destroy_workqueue | kfree(pool) # free pool time out__do_softirq run_timer_softirq # pool has already been freedThis can be easily reproduced using: 1. create thin-pool 2. dmsetup suspend pool 3. dmsetup resume pool 4. dmsetup remove_all # Concurrent with 3The root cause of this UAF bug is that dm_resume() adds timer afterdm_destroy() skips cancelling the timer because of suspend status.After timeout, it will call run_timer_softirq(), however pool hasalready been freed. The concurrency UAF bug will happen.Therefore, cancelling timer again in __pool_destroy().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-crypto: make blk_crypto_evict_key() more robustIf blk_crypto_evict_key() sees that the key is still in-use (due to abug) or that ->keyslot_evict failed, it currently just returns whileleaving the key linked into the keyslot management structures.However, blk_crypto_evict_key() is only called in contexts such as inodeeviction where failure is not an option. So actually the callerproceeds with freeing the blk_crypto_key regardless of the return valueof blk_crypto_evict_key().These two assumptions don't match, and the result is that there can be ause-after-free in blk_crypto_reprogram_all_keys() after one of theseerrors occurs. (Note, these errors *shouldn't* happen; we're justtalking about what happens if they do anyway.)Fix this by making blk_crypto_evict_key() unlink the key from thekeyslot management structures even on failure.Also improve some comments.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Simplify platform device handlingCoretemp's platform driver is unconventional. All the real work is doneglobally by the initcall and CPU hotplug notifiers, while the "driver"effectively just wraps an allocation and the registration of the hwmoninterface in a long-winded round-trip through the driver core. The wholelogic of dynamically creating and destroying platform devices to bringthe interfaces up and down is error prone, since it assumesplatform_device_add() will synchronously bind the driver and set drvdatabefore it returns, thus results in a NULL dereference if drivers_autoprobeis turned off for the platform bus. Furthermore, the unusual approach ofdoing that from within a CPU hotplug notifier, already commented in thecode that it deadlocks suspend, also causes lockdep issues for otherdrivers or subsystems which may want to legitimately register a CPUhotplug notifier from a platform bus notifier.All of these issues can be solved by ripping this unusual behaviour outcompletely, simply tying the platform devices to the lifetime of themodule itself, and directly managing the hwmon interfaces from thehotplug notifiers. There is a slight user-visible change in that/sys/bus/platform/drivers/coretemp will no longer appear, and/sys/devices/platform/coretemp.n will remain present if package n ishotplugged off, but hwmon users should really only be looking for thepresence of the hwmon interfaces, whose behaviour remains unchanged.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix use after free in midcomms commitWhile working on processing dlm message in softirq context I experiencedthe following KASAN use-after-free warning:[ 151.760477] ==================================================================[ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347[ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828[ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014[ 151.768726] Call Trace:[ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86[ 151.770556] print_report+0x180/0x4c8[ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0[ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.773069] kasan_report+0x93/0x1a0[ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.774514] __asan_load4+0x7e/0xa0[ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0[ 151.776770] send_common+0x19f/0x1b0[ 151.777342] ? remove_from_waiters+0x60/0x60[ 151.778017] ? lock_downgrade+0x410/0x410[ 151.778648] ? __this_cpu_preempt_check+0x13/0x20[ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0[ 151.780292] _convert_lock+0x46/0x150[ 151.780893] convert_lock+0x7b/0xc0[ 151.781459] dlm_lock+0x3ac/0x580[ 151.781993] ? 0xffffffffc0540000[ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70[ 151.784003] ? preempt_count_sub+0xd6/0x130[ 151.784661] ? is_module_address+0x47/0x70[ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.786166] ? 0xffffffffc0540000[ 151.786693] ? lockdep_init_map_type+0xc3/0x360[ 151.787414] ? 0xffffffffc0540000[ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.789858] ? 0xffffffffc0540000[ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture][ 151.791347] ? delay_tsc+0x94/0xc0[ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture][ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture][ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture][ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0[ 151.797152] ? mark_held_locks+0x34/0xb0[ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70[ 151.798581] ? __kthread_parkme+0x79/0x110[ 151.799246] ? trace_preempt_on+0x2a/0xf0[ 151.799902] ? __kthread_parkme+0x79/0x110[ 151.800579] ? preempt_count_sub+0xd6/0x130[ 151.801271] ? __kasan_check_read+0x11/0x20[ 151.801963] ? __kthread_parkme+0xec/0x110[ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.803569] kthread+0x192/0x1d0[ 151.804104] ? kthread_complete_and_exit+0x30/0x30[ 151.804881] ret_from_fork+0x1f/0x30[ 151.805480] [ 151.806111] Allocated by task 1347:[ 151.806681] kasan_save_stack+0x26/0x50[ 151.807308] kasan_set_track+0x25/0x30[ 151.807920] kasan_save_alloc_info+0x1e/0x30[ 151.808609] __kasan_slab_alloc+0x63/0x80[ 151.809263] kmem_cache_alloc+0x1ad/0x830[ 151.809916] dlm_allocate_mhandle+0x17/0x20[ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260[ 151.811344] _create_message+0x95/0x180[ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0[ 151.812880] send_common+0x129/0x1b0[ 151.813467] _convert_lock+0x46/0x150[ 151.814074] convert_lock+0x7b/0xc0[ 151.814648] dlm_lock+0x3ac/0x580[ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.817129] lock_t---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: ftrace: Fixup panic by disabling preemptionIn RISCV, we must use an AUIPC + JALR pair to encode an immediate,forming a jump that jumps to an address over 4K. This may cause errorsif we want to enable kernel preemption and remove dependency frompatching code with stop_machine(). For example, if a task was switchedout on auipc. And, if we changed the ftrace function before it wasswitched back, then it would jump to an address that has updated 11:0bits mixing with previous XLEN:12 part.p: patched area performed by dynamic ftraceftrace_prologue:p| REG_S ra, -SZREG(sp)p| auipc ra, 0x? ------------> preempted ... change ftrace function ...p| jalr -?(ra) <------------- switched backp| REG_L ra, -SZREG(sp)func: xxx ret
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: stricter state check in mptcp_workerAs reported by Christoph, the mptcp protocol can run theworker when the relevant msk socket is in an unexpected state:connect()// incoming reset + fastclose// the mptcp worker is scheduledmptcp_disconnect()// msk is now CLOSEDlisten()mptcp_worker()Leading to the following splat:divide error: 0000 [#1] PREEMPT SMPCPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014Workqueue: events mptcp_workerRIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_select_window net/ipv4/tcp_output.c:262 [inline] __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345 tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline] tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459 mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline] mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705 process_one_work+0x3bd/0x950 kernel/workqueue.c:2390 worker_thread+0x5b/0x610 kernel/workqueue.c:2537 kthread+0x138/0x170 kernel/kthread.c:376 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 This change addresses the issue explicitly checking for bad statesbefore running the mptcp worker.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: uclogic: Correct devm device reference for hidinput input_dev nameReference the HID device rather than the input device for the devmallocation of the input_dev name. Referencing the input_dev would lead to ause-after-free when the input_dev was unregistered and subsequently fires auevent that depends on the name. At the point of firing the uevent, thename would be freed by devres management.Use devm_kasprintf to simplify the logic for allocating memory andformatting the input_dev name string.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Address KCSAN report on bpf_lru_listKCSAN reported a data-race when accessing node->ref.Although node->ref does not have to be accurate,take this chance to use a more common READ_ONCE() and WRITE_ONCE()pattern instead of data_race().There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().This patch also adds bpf_lru_node_clear_ref() to do theWRITE_ONCE(node->ref, 0) also.==================================================================BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elemwrite to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi->poll_ownernon atomically. The ->poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free in hdcpThe HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connectorobjects without incrementing the kref reference counts. When using aUSB-C dock, and the dock is unplugged, the correspondingamdgpu_dm_connector objects are freed, creating dangling pointers in theHDCP code. When the dock is plugged back, the dangling pointers aredereferenced, resulting in a slab-use-after-free:[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024[ 66.776186] Workqueue: events event_property_validate [amdgpu][ 66.776494] Call Trace:[ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0[ 66.776504] print_report+0x175/0x555[ 66.776507] ? __virt_addr_valid+0x243/0x450[ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0[ 66.776515] kasan_report+0xeb/0x1c0[ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777121] __asan_report_load4_noabort+0x14/0x20[ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777342] ? __lock_acquire+0x6b40/0x6b40[ 66.777347] ? enable_assr+0x250/0x250 [amdgpu][ 66.777571] process_one_work+0x86b/0x1510[ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0[ 66.777578] ? assign_work+0x16b/0x280[ 66.777580] ? lock_is_held_type+0xa3/0x130[ 66.777583] worker_thread+0x5c0/0xfa0[ 66.777587] ? process_one_work+0x1510/0x1510[ 66.777588] kthread+0x3a2/0x840[ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777594] ? trace_hardirqs_on+0x4f/0x60[ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60[ 66.777599] ? calculate_sigpending+0x77/0xa0[ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777605] ret_from_fork+0x40/0x90[ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777609] ret_from_fork_asm+0x11/0x20[ 66.777614] [ 66.777643] Allocated by task 10:[ 66.777646] kasan_save_stack+0x39/0x60[ 66.777649] kasan_save_track+0x14/0x40[ 66.777652] kasan_save_alloc_info+0x37/0x50[ 66.777655] __kasan_kmalloc+0xbb/0xc0[ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0[ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu][ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper][ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper][ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper][ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper][ 66.777917] process_one_work+0x86b/0x1510[ 66.777919] worker_thread+0x5c0/0xfa0[ 66.777922] kthread+0x3a2/0x840[ 66.777925] ret_from_fork+0x40/0x90[ 66.777927] ret_from_fork_asm+0x11/0x20[ 66.777932] Freed by task 1713:[ 66.777935] kasan_save_stack+0x39/0x60[ 66.777938] kasan_save_track+0x14/0x40[ 66.777940] kasan_save_free_info+0x3b/0x60[ 66.777944] __kasan_slab_free+0x52/0x70[ 66.777946] kfree+0x13f/0x4b0[ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu][ 66.778179] drm_connector_free+0x7d/0xb0[ 66.778184] drm_mode_object_put.part.0+0xee/0x160[ 66.778188] drm_mode_object_put+0x37/0x50[ 66.778191] drm_atomic_state_default_clear+0x220/0xd60[ 66.778194] __drm_atomic_state_free+0x16e/0x2a0[ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0[ 66.778200] drm_ioctl_kernel+0x17a/0x310[ 66.778203] drm_ioctl+0x584/0xd10[ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu][ 66.778375] __x64_sys_ioctl+0x139/0x1a0[ 66.778378] x64_sys_call+0xee7/0xfb0[ 66.778381] ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Add missing lockingRecent kernels complain about a missing lock in k3-udma.c when the lockvalidator is enabled:[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28[ 4.144867] Hardware name: pp-v12 (DT)[ 4.148648] Workqueue: events udma_check_tx_completion[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.160834] pc : udma_start.isra.0+0x34/0x238[ 4.165227] lr : udma_start.isra.0+0x30/0x238[ 4.169618] sp : ffffffc083cabcf0[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000[ 4.244986] Call trace:[ 4.247463] udma_start.isra.0+0x34/0x238[ 4.251509] udma_check_tx_completion+0xd0/0xdc[ 4.256076] process_one_work+0x244/0x3fc[ 4.260129] process_scheduled_works+0x6c/0x74[ 4.264610] worker_thread+0x150/0x1dc[ 4.268398] kthread+0xd8/0xe8[ 4.271492] ret_from_fork+0x10/0x20[ 4.275107] irq event stamp: 220[ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50[ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50[ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc[ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28[ 4.311559] ---[ end trace 0000000000000000 ]---This commit adds the missing locking.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookieThe IOMMU translation for MSI message addresses has been a 2-step process,separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.This has an inherent lifetime problem for the pointer stored in the cookiethat must remain valid between the two steps. However, there is no lockingat the irq layer that helps protect the lifetime. Today, this works underthe assumption that the iommu domain is not changed while MSI interruptsbeing programmed. This is true for normal DMA API users within the kernel,as the iommu domain is attached before the driver is probed and cannot bechanged while a driver is attached.Classic VFIO type1 also prevented changing the iommu domain while VFIO wasrunning as it does not support changing the "container" after starting up.However, iommufd has improved this so that the iommu domain can be changedduring VFIO operation. This potentially allows userspace to directly raceVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) andVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).This potentially causes both the cookie pointer and the unlocked call toiommu_get_domain_for_dev() on the MSI translation path to become UAFs.Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVAaddress is already known during iommu_dma_prepare_msi() and cannot change.Thus, it can simply be stored as an integer in the MSI descriptor.The other UAF related to iommu_get_domain_for_dev() will be addressed inpatch "iommu: Make iommu_dma_prepare_msi() into a generic operation" byusing the IOMMU group mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: unshare page tables during VMA split, not beforeCurrently, __split_vma() triggers hugetlb page table unsharing throughvm_ops->may_split(). This happens before the VMA lock and rmap locks aretaken - which is too early, it allows racing VMA-locked page faults in ourprocess and racing rmap walks from other processes to cause page tables tobe shared again before we actually perform the split.Fix it by explicitly calling into the hugetlb unshare logic from__split_vma() in the same place where THP splitting also happens. At thatpoint, both the VMA and the rmap(s) are write-locked.An annoying detail is that we can now call into the helperhugetlb_unshare_pmds() from two different locking contexts:1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively)2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lockBackporting note:This commit fixes a racy protection that was introduced in commitb30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); thatcommit claimed to fix an issue introduced in 5.13, but it should actuallyalso go all the way back.[jannh@google.com: v2]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Protect mgmt_pending list with its own lockThis uses a mutex to protect from concurrent access of mgmt_pendinglist which can cause crashes like:==================================================================BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Avoid using sk_socket after free when sendingThe sk->sk_socket is not locked or referenced in backlog thread, andduring the call to skb_send_sock(), there is a race condition withthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)will be affected.Race conditions:'''CPU0 CPU1backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here'''The ref of psock become 0 after sock_map_close() executed.'''void sock_map_close(){ ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ...}'''Based on the fact that we already wait for the workqueue to finish insock_map_close() if psock is held, we simply increase the psockreference count to avoid race conditions.With this patch, if the backlog thread is running, sock_map_close() willwait for the backlog thread to complete and cancel all pending work.If no backlog running, any pending work that hasn't started by then willfail when invoked by sk_psock_get(), as the psock reference count havebeen zeroed, and sk_psock_drop() will cancel all jobs viacancel_delayed_work_sync().In summary, we require synchronization to coordinate the backlog threadand close() thread.The panic I catched:'''Workqueue: events sk_psock_backlogRIP: 0010:sock_sendmsg+0x21d/0x440RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001...Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80...'''
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: validate AG parameters in dbMount() to prevent crashesValidate db_agheight, db_agwidth, and db_agstart in dbMount to catchcorrupted metadata early and avoid undefined behavior in dbAllocAG.Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:- agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0.- agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0.- agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9shift exponent -335544310 is negativeCPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check return result of sb_min_blocksizeSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.Syzkaller forks multiple processes which after mounting the Squashfsfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in theprocess of mounting a Squashfs filesystem on /dev/loop0, the failureoccurs. When this happens the following code in squashfs_fill_super()fails.----msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);msblk->devblksize_log2 = ffz(~msblk->devblksize);----sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2is set to 64.This subsequently causes theUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36shift exponent 64 is too large for 64-bit type 'u64' (aka'unsigned long long')This commit adds a check for a 0 return by sb_min_blocksize().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: uart: Set tty->disc_data only in success pathSetting tty->disc_data before opening the NCI device means we need toclean it up on error paths. This also opens some short window if devicestarts sending data, even before NCIUARTSETDRIVER IOCTL succeeded(broken hardware?). Close the window by exposing tty->disc_data only onthe success path, when opening of the NCI device and try_module_get()succeeds.The code differs in error path in one aspect: tty->disc_data won't beever assigned thus NULL-ified. This however should not be relevantdifference, because of "tty->disc_data=NULL" in nci_uart_tty_open().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike "sg_write_same --ndob" we will crash in target_core_iblock/file'sexecute_write_same handlers when we go to access the se_cmd->t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don't support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libabsl2401_0_0 > 0-0 (version in image is 20240116.1-150500.13.7.8).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.32.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devicesMaximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kband 64 Kb respectively. Adjust max size definitions and return correctEEPROM length based on device. Also prevent out-of-bound read/write.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:iavf: fix off-by-one issues in iavf_config_rss_reg()There are off-by-one bugs when configuring RSS hash key and lookuptable, causing out-of-bounds reads to memory [1] and out-of-boundswrites to device registers.Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4where `rss_{key,lut}_size / 4` is the number of dwords, so the lastvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`accesses one element past the end.Fix the issues by using `<` instead of `<=`, ensuring we do not exceedthe bounds.[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63 CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scs: fix a wrong parameter in __scs_magic__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' isgiven. 'task_scs(tsk)' is the starting address of the task's shadow callstack, and '__scs_magic(task_scs(tsk))' is the end address of the task'sshadow call stack. Here should be '__scs_magic(task_scs(tsk))'.The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGEis enabled, the shadow call stack usage checking function(scs_check_usage) would scan an incorrect memory range. This could lead1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg.2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses).However, since this is purely a debugging feature(CONFIG_DEBUG_STACK_USAGE), normal production systems should be notunaffected. The bug only impacts developers and testers who are activelydebugging stack usage with this configuration enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix a use-after-freeThere are two .exit_cmd_priv implementations. Both implementations useresources associated with the SCSI host. Make sure that these resources arestill available when .exit_cmd_priv is called by waiting insidescsi_remove_host() until the tag set has been freed.This commit fixes the following use-after-free:==================================================================BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]Read of size 8 at addr ffff888100337000 by task multipathd/16727Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()While looking at one unrelated syzbot bug, I found the replay logicin __rtnl_newlink() to potentially trigger use-after-free.It is better to clear master_dev and m_ops inside the loop,in case we have to replay it.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix information leakage in /proc/net/ptypeIn one net namespace, after creating a packet socket without bindingit to a device, users in other net namespaces can observe the new`packet_type` added by this packet socket by reading `/proc/net/ptype`file. This is minor information leakage as packet socket isnamespace aware.Add a net pointer in `packet_type` to keep the net namespace ofof corresponding packet socket. In `ptype_seq_show`, this net pointermust be checked when it is not NULL.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we're operating on annon-uptodate page. Our overnight tests caught this warning earlier thisweek WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ("btrfs: clear extent bufferuptodate when we fail to write it"), however all that fix did was keepus from finding extent buffers after a failed writeout. It didn't keepus from continuing to use a buffer that we already had found.In this case we're searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing. After the switch we can look up an extentbuffer that hasn't been written yet and start processing that blockgroup. Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we're protected by the tree lock to a certain degree here. Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write. However thisisn't necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon't save us here. We'll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we've "read" a block butit's not marked Uptodate. On read we ClearPageError(), so if we're!Uptodate and !Error we know we didn't do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we're using it, and we'll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we're messing with it.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: fix oops caused by irqsoff latency tracerThe trace_hardirqs_{on,off}() require the caller to setup frame pointerproperly. This because these two functions use macro 'CALLER_ADDR1' (aka.__builtin_return_address(1)) to acquire caller info. If the $fp is usedfor other purpose, the code generated this macro (as below) could triggermemory access fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault hereThe oops message during booting if compiled with 'irqoff' tracer enabled:[ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8[ 0.041925][ T0] Oops [#1][ 0.042063][ T0] Modules linked in:[ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29[ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT)[ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2[ 0.044601][ T0] ra : restore_all+0x12/0x6e[ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0[ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020[ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0[ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100[ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000[ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45[ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50[ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8[ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000[ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000[ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368[ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d[ 0.046402][ T0] [] restore_all+0x12/0x6eThis because the $fp(aka. $s0) register is not used as frame pointer in theassembly entry code. resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_allTo fix above issue, here we add one extra level wrapper for functiontrace_hardirqs_{on,off}() so they can be safely called by low level entrycode.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memory leak during stateful obj updatestateful objects can be updated from the control plane.The transaction logic allocates a temporary object for this purpose.The ->init function was called for this object, so plain kfree() leaksresources. We must call ->destroy function of the object.nft_obj_destroy does this, but it also decrements the module refcount,but the update path doesn't increment it.To avoid special-casing the update object release, do module_get forthe update case too and release it via nft_obj_destroy().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: mt7621: Add sentinel to quirks tableCurrent driver is missing a sentinel in the struct soc_device_attributearray, which causes an oops when assessed by thesoc_device_match(mt7621_pcie_quirks_match) call.This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attrwas fixed to register the SOC as a device, in:commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")Fix it by adding the required sentinel.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix memory leak in sctp_stream_outq_migrate()When sctp_stream_outq_migrate() is called to release stream out resources,the memory pointed to by prio_head in stream out is not released.The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Handle size overflow for ringbuf mmapThe maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entrieswill overflow u32 when mapping producer page and data pages. Onlycasting max_entries to size_t is not enough, because for 32-bitsapplication on 64-bits kernel the size of read-only mmap regionalso could overflow size_t.So fixing it by casting the size of read-only mmap region into a __u64and checking whether or not there will be overflow during mmap.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix panic when growing a memfd_secretWhen one tries to grow an existing memfd_secret with ftruncate, one getsa panic [1]. For example, doing the following reliably induces thepanic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20);The basic reason for this is, when we grow with ftruncate, we call downinto simple_setattr, and then truncate_inode_pages_range, and eventuallywe try to zero part of the memory. The normal truncation code does thisvia the direct map (i.e., it calls page_address() and hands that tomemset()).For memfd_secret though, we specifically don't map our pages via thedirect map (i.e. we call set_direct_map_invalid_noflush() on everyfault). So the address returned by page_address() isn't useful, andwhen we try to memset() with it we panic.This patch avoids the panic by implementing a custom setattr formemfd_secret, which detects resizes specifically (setting the size forthe first time works just fine, since there are no existing pages to tryto zero), and rejects them with EINVAL.One could argue growing should be supported, but I think that willrequire a significantly more lengthy change. So, I propose a minimalfix for the benefit of stable kernels, and then perhaps to extendmemfd_secret to support growing in a separate patch.[1]: BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028[lkp@intel.com: secretmem_iops can be static][axelrasmussen@google.com: return EINVAL]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix a race in rxrpc_exit_net()Current code can lead to the following race:CPU0 CPU1rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work);rxrpc_exit_net() exits while peer_keepalive_timer is still armed,leading to use-after-free.syzbot report was:ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505Modules linked in:CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix slab-out-of-bounds bug in decrypt_internalThe memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting intls_set_sw_offload(). The return value of crypto_aead_ivsize()for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytesmemory space will trigger slab-out-of-bounds bug as following:==================================================================BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]Read of size 16 at addr ffff888114e84e60 by task tls/10911Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls]Allocated by task 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_sizewhen memcpy() iv value in TLS_1_3_VERSION scenario.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ref_tracker: implement use-after-free detectionWhenever ref_tracker_dir_init() is called, mark the struct ref_tracker_diras dead.Test the dead status from ref_tracker_alloc() and ref_tracker_free()This should detect buggy dev_put()/dev_hold() happening too latein netdevice dismantle process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: felix: fix possible NULL pointer dereferenceAs the possible failure of the allocation, kzalloc() may return NULLpointer.Therefore, it should be better to check the 'sgi' in order to preventthe dereference of NULL pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probeThe device_node pointer is returned by of_parse_phandle() with refcountincremented. We should use of_node_put() on it when done.This function only calls of_node_put() in the regular path.And it will cause refcount leak in error paths.Fix this by calling of_node_put() in error handling too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not double complete bio on errors during compressed readsI hit some weird panics while fixing up the error handling frombtrfs_lookup_bio_sums(). Turns out the compression path will completethe bio we use if we set up any of the compression bios and then returnan error, and then btrfs_submit_data_bio() will also call bio_endio() onthe bio.Fix this by making btrfs_submit_compressed_read() responsible forcalling bio_endio() on the bio if there are any errors. Currently itwas only doing it if we created the compression bios, otherwise it wasdepending on btrfs_submit_data_bio() to do the right thing. Thiscreates the above problem, so fix up btrfs_submit_compressed_read() toalways call bio_endio() in case of an error, and then simply return frombtrfs_submit_data_bio() if we had to callbtrfs_submit_compressed_read().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not clean up repair bio if submit failsThe submit helper will always run bio_endio() on the bio if it fails tosubmit, so cleaning up the bio just leads to a variety of use-after-freeand NULL pointer dereference bugs because we race with the endiofunction that is cleaning up the bio. Instead just return BLK_STS_OK asthe repair function has to continue to process the rest of the pages,and the endio for the repair bio will do the appropriate cleanup for thepage that it was given.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Hold port reference until decoder releaseKASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free incxl_decoder_release() where it goes to reference its parent, a cxl_port,to free its id back to port->decoder_ida. BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core] Read of size 8 at addr ffff888119270908 by task kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events kobject_delayed_cleanup Call Trace: dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0The device core only guarantees parent lifetime until all children areunregistered. If a child needs a parent to complete its ->release()callback that child needs to hold a reference to extend the lifetime ofthe parent.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: unregister virtual clocks when unregistering physical clock.When unregistering a physical clock which has some virtual clocks,unregister the virtual clocks with it.This fixes the following oops, which can be triggered by unloadinga driver providing a PTP clock when it has enabled virtual clocks:BUG: unable to handle page fault for address: ffffffffc04fc4d8Oops: 0000 [#1] PREEMPT SMP NOPTIRIP: 0010:ptp_vclock_read+0x31/0xb0Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Avoid cross-chip syncing of VLAN filteringChanges to VLAN filtering are not applicable to cross-chipnotifications.On a system like this:.-----. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-' '-1-2-' '-1-2-'Before this change, upon sw1p1 leaving a bridge, a call todsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.In this scenario:.---------. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-3-4-' '-1-2-' '-1-2-'When sw1p4 would leave a bridge, dsa_port_vlan_filtering would becalled for sw2 and sw3 with a non-existing port - leading to arrayout-of-bounds accesses and crashes on mv88e6xxx.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip_gre: test csum_start instead of transport headerGRE with TUNNEL_CSUM will apply local checksum offload onCHECKSUM_PARTIAL packets.ipgre_xmit must validate csum_start after an optional skb_pull,else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL;This had false positives when skb_checksum_start is undefined:when ip_summed is not CHECKSUM_PARTIAL. A discussed refinementwas straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL;But was eventually revised more thoroughly:- restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull.- test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath.Turns out skbs can arrive in this branch without the transportheader set, e.g., through BPF redirection.Revise the check back to check csum_start directly, and only ifCHECKSUM_PARTIAL. Do leave the check in the updated location.Check field regardless of whether TUNNEL_CSUM is configured.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: memleak flow rule from commit pathAbort path release flow rule object, however, commit path does not.Update code to destroy these objects before releasing the transaction.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate races around sk->sk_bound_dev_ifUDP sendmsg() is lockless, and reads sk->sk_bound_dev_if whilethis field can be changed by another thread.Adds minimal annotations to avoid KCSAN splats for UDP.Following patches will add more annotations to potential lockless readers.BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsgwrite to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0x00000000 -> 0xffffff9bReported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011I chose to not add Fixes: tag because race has minor consequencesand stable teams busy enough.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix anon_dev leak in create_subvol()When btrfs_qgroup_inherit(), btrfs_alloc_tree_block, orbtrfs_insert_root() fail in create_subvol(), we return without freeinganon_dev. Reorganize the error handling in create_subvol() to fix this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: cfo: check mac_id to avoid out-of-boundsSomehow, hardware reports incorrect mac_id and pollute memory. Check indexbefore we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.koIf the driver support subdev mode, the parameter "dev->pm.dev" will beNULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmodmtk-vcodec-dec.ko.[ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80[ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c[ 4380.711509] sp : ffff80000819bc10[ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000[ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220[ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020[ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976[ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040[ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000[ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc[ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000[ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208[ 4380.786031] Call trace:[ 4380.788465] do_raw_spin_trylock+0x4/0x80[ 4380.792462] __pm_runtime_disable+0x2c/0x1b0[ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec][ 4380.802466] platform_remove+0x2c/0x60[ 4380.806204] __device_release_driver+0x194/0x250[ 4380.810810] driver_detach+0xc8/0x15c[ 4380.814462] bus_remove_driver+0x5c/0xb0[ 4380.818375] driver_unregister+0x34/0x64[ 4380.822288] platform_driver_unregister+0x18/0x24[ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec][ 4380.833240] __arm64_sys_delete_module+0x190/0x224[ 4380.838020] invoke_syscall+0x48/0x114[ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c[ 4380.846540] do_el0_svc+0x28/0x90[ 4380.849844] el0_svc+0x4c/0x100[ 4380.852975] el0t_64_sync_handler+0xec/0xf0[ 4380.857148] el0t_64_sync+0x190/0x194[ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: dw9714: Disable the regulator when the driver fails to probeWhen the driver fails to probe, we will get the following splat:[ 59.305988] ------------[ cut here ]------------[ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0[ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0[ 59.318362] Call Trace:[ 59.318582] [ 59.318765] regulator_put+0x1f/0x30[ 59.319058] devres_release_group+0x319/0x3d0[ 59.319420] i2c_device_probe+0x766/0x940Fix this by disabling the regulator in error handling.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Fix data-races around nexthop_compat_mode.While reading nexthop_compat_mode, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: Fix data-races around sysctl_icmp_echo_enable_probe.While reading sysctl_icmp_echo_enable_probe, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix a data-race around sysctl_fib_sync_mem.While reading sysctl_fib_sync_mem, it can be changed concurrently.So, we need to add READ_ONCE() to avoid a data-race.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Use "buf" flexible array for memcpy() destinationThe "buf" flexible array needs to be the memcpy() destination to avoidfalse positive run-time warning from the recent FORTIFY_SOURCEhardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: use casting of u64 in clock multiplication to avoid overflowIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflowby depending on the values of the given parameters including the ic_clk.For example in our use case where ic_clk is larger than one million,multiplication of ic_clk * 4700 will result in 32 bit overflow.Add cast of u64 to the calculation to avoid multiplication overflow, anduse the corresponding define for divide.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/highbank: Fix memory leak in highbank_mc_probe()When devres_open_group() fails, it returns -ENOMEM without freeing memoryallocated by edac_mc_alloc().Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:reset: uniphier-glue: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(res) invoked,if platform_get_resource() returns NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always report error in run_one_delayed_ref()Currently we have a btrfs_debug() for run_one_delayed_ref() failure, butif end users hit such problem, there will be no chance thatbtrfs_debug() is enabled. This can lead to very little useful info fordebugging.This patch will:- Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod- Replace the btrfs_debug() with btrfs_err()- Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller.This error should only be triggered at most once.As if run_one_delayed_ref() failed, we trigger the error message, thencausing the call chain to error out:btrfs_run_delayed_refs()`- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref()And we will abort the current transaction in btrfs_run_delayed_refs().If we have to run delayed refs for the abort transaction,run_one_delayed_ref() will just cleanup the refs and do nothing, thus nonew error messages would be output.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent bpf program recursion for raw tracepoint probesWe got report from sysbot [1] about warnings that were caused bybpf program attached to contention_begin raw tracepoint triggeringthe same tracepoint by using bpf_trace_printk helper that takestrace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ...The can be reproduced by attaching bpf program as raw tracepoint oncontention_begin tracepoint. The bpf prog calls bpf_trace_printkhelper. Then by running perf bench the spin lock code is forced totake slow path and call contention_begin tracepoint.Fixing this by skipping execution of the bpf program if it'salready running, Using bpf prog 'active' field, which is beingcurrently used by trampoline programs for the same reason.Moving bpf_prog_inc_misses_counter to syscall.c becausetrampoline.c is compiled in just for CONFIG_BPF_JIT option.[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p: trans_fd/p9_conn_cancel: drop client lock earliersyzbot reported a double-lock here and we no longer need thislock after requests have been moved off to local list:just drop the lock earlier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Add overflow check in sgx_validate_offset_length()sgx_validate_offset_length() function verifies "offset" and "length"arguments provided by userspace, but was missing an overflow check ontheir addition. Add it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: Fix memory leak of nsim_dev->fa_cookiekmemleak reports this issue:unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe issue occurs in the following scenarios:nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie..nsim_drv_remove()The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. Tofix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()sparx_stats_init() calls create_singlethread_workqueue() and notchecked the ret value, which may return NULL. And a null-ptr-deref mayhappen:sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL. So assparx5_start().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: don't leak tagger-owned storage on switch driver unbindIn the initial commit dc452a471dba ("net: dsa: introduce tagger-ownedstorage for private and shared data"), we had a call totag_ops->disconnect(dst) issued from dsa_tree_free(), which is called attree teardown time.There were problems with connecting to a switch tree as a whole, so thisgot reworked to connecting to individual switches within the tree. Inthis process, tag_ops->disconnect(ds) was made to be called only fromswitch.c (cross-chip notifiers emitted as a result of dynamic tag protochanges), but the normal driver teardown code path wasn't replaced withanything.Solve this problem by adding a function that does the opposite ofdsa_switch_setup_tag_protocol(), which is called from the equivalentspot in dsa_switch_teardown(). The positioning here also ensures that wewon't have any use-after-free in tagging protocol (*rcv) ops, since theteardown sequence is as follows:dsa_tree_teardown-> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler-> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many()-> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: don't delete error page from pagecacheThis change is very similar to the change that was made for shmem [1], andit solves the same problem but for HugeTLBFS instead.Currently, when poison is found in a HugeTLB page, the page is removedfrom the page cache. That means that attempting to map or read thathugepage in the future will result in a new hugepage being allocatedinstead of notifying the user that the page was poisoned. As [1] states,this is effectively memory corruption.The fix is to leave the page in the page cache. If the user attempts touse a poisoned HugeTLB page with a syscall, the syscall will fail withEIO, the same error code that shmem uses. For attempts to map the page,the thread will get a BUS_MCEERR_AR SIGBUS.[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: initialize device's zone info for seedingWhen performing seeding on a zoned filesystem it is necessary toinitialize each zoned device's btrfs_zoned_device_info structure,otherwise mounting the filesystem will cause a NULL pointer dereference.This was uncovered by fstests' testcase btrfs/163.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: clone zoned device info when cloning a deviceWhen cloning a btrfs_device, we're not cloning the associatedbtrfs_zoned_device_info structure of the device in case of a zonedfilesystem.Later on this leads to a NULL pointer dereference when accessing thedevice's zone_info for instance when setting a zone as active.This was uncovered by fstests' testcase btrfs/161.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()We got a syzkaller problem because of aarch64 alignment faultif KFENCE enabled. When the size from user bpf program is an oddnumber, like 399, 407, etc, it will cause the struct skb_shared_info'sunaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381To fix the problem, we adjust @size so that (@size + @hearoom) is amultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_infois aligned to a cache line.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix panic on frag_list with mixed head alloc typesSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat whensplitting gso_size mangled skb having linear-headed frag_list"), it isallowed to change gso_size of a GRO packet. However, that commit assumesthat "checking the first list_skb member suffices; i.e if either of thelist_skb members have non head_frag head, then the first one has too".It turns out this assumption does not hold. We've seen BUG_ON being hitin skb_segment when skbs on the frag_list had differing head_frag withthe vmxnet3 driver. This happens because __netdev_alloc_skb and__napi_alloc_skb can return a skb that is page backed or kmalloceddepending on the requested size. As the result, the last small skb inthe GRO packet can be kmalloced.There are three different locations where this can be fixed:(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list.(3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down.This patch implements (3). To limit the performance impact inskb_segment, the list is walked only for skbs with SKB_GSO_DODGY setthat have gso_size changed. Normal paths thus will not hit it.We could check only the last skb but since we need to walk the wholelist anyway, let's stay on the safe side.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queuesWhen running `test_sockmap` selftests, the following warning appears: WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root case is in commit 84472b436e76 ("bpf, sockmap: Fix more unchargedwhile msg has more_data"), where I used msg->sg.size to replace the tosend,causing breakage: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes;
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix WARNING in ip6_route_net_exit_late()During the initialization of ip6_route_net_init_late(), if fileipv6_route or rt6_stats fails to be created, the initialization issuccessful by default. Therefore, the ipv6_route or rt6_stats filedoesn't be found during the remove in ip6_route_net_exit_late(). Itwill cause WRNING.The following is the stack information:name 'rt6_stats'WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460PKRU: 55555554Call Trace:ops_exit_list+0xb0/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix warning in ext4_iomap_begin as race between bmap and writeWe got issue as follows:------------[ cut here ]------------WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0RIP: 0010:ext4_iomap_begin+0x182/0x5d0RSP: 0018:ffff88812460fa08 EFLAGS: 00010293RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20fR10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691eeFS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Above issue may happen as follows: bmap writebmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_onTo solved above issue hold inode lock in ext4_bamp.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix memory leak when using fscacheIf we hit the 'index == next_cached' case, we leak a refcount on thestruct page. Fix this by using readahead_folio() which takes care ofthe refcount for you.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: core: set smem_len before fb_deferred_io_init callThe fbtft_framebuffer_alloc() calls fb_deferred_io_init() beforeinitializing info->fix.smem_len. It is set to zero by theframebuffer_alloc() function. It will trigger a WARN_ON() at thestart of fb_deferred_io_init() and the function will not do anything.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: check previous kernel's ima-kexec-buffer against memory boundsPresently ima_get_kexec_buffer() doesn't check if the previous kernel'sima-kexec-buffer lies outside the addressable memory range. This can resultin a kernel panic if the new kernel is booted with 'mem=X' arg and theima-kexec-buffer was allocated beyond that range by the previous kernel.The panic is usually of the form below:$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---Fix this issue by checking returned PFN range of previous kernel'sima-kexec-buffer with page_is_ram() to ensure correct memory bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, x86: fix freeing of not-finalized bpf_prog_packsyzbot reported a few issues with bpf_prog_pack [1], [2]. This only happenswith multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile()on each sub program. And then, we call it on each sub program again. jit_datais not freed in the first call of bpf_int_jit_compile(). Similarly we don'tcall bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile().If bpf_int_jit_compile() failed for one sub program, we will callbpf_jit_binary_pack_finalize() for this sub program. However, we don't have achance to call it for other sub programs. Then we will hit "goto out_free" injit_subprogs(), and call bpf_jit_free on some subprograms that haven't gotbpf_jit_binary_pack_finalize() yet.At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page isfreed erroneously.Fix this with a custom bpf_jit_free() for x86_64, which callsbpf_jit_binary_pack_finalize() if necessary. Also, with custombpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more,remove it.[1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f[2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Treat NX as a valid SPTE bit for NPTTreat the NX bit as valid when using NPT, as KVM will set the NX bit whenthe NX huge page mitigation is enabled (mindblowing) and trigger the WARNthat fires on reserved SPTE bits being set.KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:Refuse to load kvm_amd if NX support is not available") for exactly thisreason, but apparently it never occurred to anyone to actually test NPTwith the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix crash on isr after kexec()If the system is rebooted via isr(), the IRQ handler mightbe triggered before the domain is initialized. Resulting onan invalid memory access error.Fix:[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070[ 0.501166] Call trace:[ 0.501174] report_iommu_fault+0x28/0xfc[ 0.501180] mtk_iommu_isr+0x10c/0x1c0[ joro: Fixed spelling in commit message ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: handle the error returned from sctp_auth_asoc_init_active_keyWhen it returns an error from sctp_auth_asoc_init_active_key(), theactive_key is actually not updated. The old sh_key will be freeedwhile it's still used as active key in asoc. Then an use-after-freewill be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734This patch is to fix it by not replacing the sh_key when it returnserrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().For sctp_auth_set_active_key(), old active_key_id will be set backto asoc->active_key_id when the same thing happens.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()If device_register() fails in cxl_pci_afu|adapter(), the deviceis not added, device_unregister() can not be called in the errorpath, otherwise it will cause a null-ptr-deref because of removingnot added device.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: fix race in sock_map_free()sock_map_free() calls release_sock(sk) without owning a referenceon the socket. This can cause use-after-free as syzbot found [1]Jakub Sitnicki already took care of a similar issuein sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:Synchronize delete from bucket list on map free")[1]refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Modules linked in:CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: events_unbound bpf_map_free_deferredRIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ffRSP: 0018:ffffc9000456fb60 EFLAGS: 00010246RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcfFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__refcount_dec include/linux/refcount.h:344 [inline]refcount_dec include/linux/refcount.h:359 [inline]__sock_put include/net/sock.h:779 [inline]tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092release_sock+0xaf/0x1c0 net/core/sock.c:3468sock_map_free+0x219/0x2c0 net/core/sock_map.c:356process_one_work+0x81c/0xd10 kernel/workqueue.c:2289worker_thread+0xb14/0x1330 kernel/workqueue.c:2436kthread+0x266/0x300 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_waitkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.syzbot reported:BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfreewrite to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on destination blkaddr during recoveryAs Wenqing Liu reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=216456loop5: detected capacity change from 0 to 131072F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): Bitmap was wrongly set, blk:5634------------[ cut here ]------------WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]Call Trace: f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdIf we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panicinstead of warning.The root cause is: in fuzzed image, SIT table is inconsistent with inodemapping table, result in triggering such warning during SIT table update.This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ thisflag, data block recovery flow can check destination blkaddr's validationin SIT table, and skip f2fs_replace_block() to avoid inconsistent status.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pnode: terminate at peers of sourceThe propagate_mnt() function handles mount propagation when creatingmounts and propagates the source mount tree @source_mnt to allapplicable nodes of the destination propagation mount tree headed by@dest_mnt.Unfortunately it contains a bug where it fails to terminate at peers of@source_mnt when looking up copies of the source mount that becomemasters for copies of the source mount tree mounted on top of slaves inthe destination propagation tree causing a NULL dereference.Once the mechanics of the bug are understood it's easy to trigger.Because of unprivileged user namespaces it is available to unprivilegedusers.While fixing this bug we've gotten confused multiple times due tounclear terminology or missing concepts. So let's start this with someclarifications:* The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group.* A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share.* The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list.* The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group.* Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked.* Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from.* A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups.* A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group.* A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group pr---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_psockkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.We do the same for kcm->rx_wait in the following patch.syzbot reported:BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcmwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff88812971ce00 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a rangeIf we get -ENOMEM while dropping file extent items in a given range, atbtrfs_drop_extents(), due to failure to allocate memory when attempting toincrement the reference count for an extent or drop the reference count,we handle it with a BUG_ON(). This is excessive, instead we can simplyabort the transaction and return the error to the caller. In fact mostcallers of btrfs_drop_extents(), directly or indirectly, already abortthe transaction if btrfs_drop_extents() returns any error.Also, we already have error paths at btrfs_drop_extents() that may return-ENOMEM and in those cases we abort the transaction, like for exampleanything that changes the b+tree may return -ENOMEM due to a failure toallocate a new extent buffer when COWing an existing extent buffer, suchas a call to btrfs_duplicate_item() for example.So replace the BUG_ON() calls with proper logic to abort the transactionand return the error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: core: fix possible resource leak in init_mtd()I got the error report while inject fault in init_mtd():sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'Call Trace: dump_stack_lvl+0x67/0x83 sysfs_warn_dup+0x60/0x70 sysfs_create_dir_ns+0x109/0x120 kobject_add_internal+0xce/0x2f0 kobject_add+0x98/0x110 device_add+0x179/0xc00 device_create_groups_vargs+0xf4/0x100 device_create+0x7b/0xb0 bdi_register_va.part.13+0x58/0x2d0 bdi_register+0x9b/0xb0 init_mtd+0x62/0x171 [mtd] do_one_initcall+0x6c/0x3c0 do_init_module+0x58/0x222 load_module+0x268e/0x27d0 __do_sys_finit_module+0xd5/0x140 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory.Error registering mtd class or bdi: -17If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,as a result, we can't load the mtd module again, to fix this by callingbdi_unregister(mtd_bdi) after out_procfs label.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix refcount leak in cxl_calc_capp_routingof_get_next_parent() returns a node pointer with refcount incremented,we should use of_node_put() on it when not need anymore.This function only calls of_node_put() in normal path,missing it in the error path.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_sysfs_init()When insert and remove the orangefs module, there are kobjects memoryleaked as below:unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns: fix possible memory leak in hnae_ae_register()Inject fault while probing module, if device_register() fails,but the refcount of kobject is not decreased to 0, the nameallocated in dev_set_name() is leaked. Fix this by callingput_device(), so that name can be freed in callback functionkobject_cleanup().unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: vme_user: Fix possible UAF in tsi148_dma_list_addSmatch report warning as follows:drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from listIn tsi148_dma_list_add(), the error path "goto err_dma" will notremove entry->list from list->entries, but entry will be freed,then list traversal may cause UAF.Fix by removeing it from list->entries before free().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init()If of_iomap() failed, 'aic' should be freed before return. Otherwisethere is a memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/gntdev: Accommodate VMA splittingPrior to this commit, the gntdev driver code did not handle thefollowing scenario correctly with paravirtualized (PV) Xen domains:* User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain).* User process munmap()s one of the pages.* User process munmap()s the remaining page.* User process exits.In the scenario above, the user process would cause the kernel to logthe following messages in dmesg for the first munmap(), and the secondmunmap() call would result in similar log messages: BUG: Bad page map in process doublemap.test pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... page dumped because: bad pte ... file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0 ... Call Trace: dump_stack_lvl+0x46/0x5e print_bad_pte.cold+0x66/0xb6 unmap_page_range+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110 __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_munmap+0x28/0x40 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb ...For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG)would print out the following and trigger a general protection fault inthe affected Xen PV domain: (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...As of this writing, gntdev_grant_map structure's vma field (referred toas map->vma below) is mainly used for checking the start and endaddresses of mappings. However, with split VMAs, these may change, andthere could be more than one VMA associated with a gntdev mapping.Hence, remove the use of map->vma and rely on map->pages_vm_start forthe original start address and on (map->count << PAGE_SHIFT) for theoriginal mapping size. Let the invalidate() and find_special_page()hooks use these.Also, given that there can be multiple VMAs associated with a gntdevmapping, move the "mmu_interval_notifier_remove(&map->notifier)" call tothe end of gntdev_put_map, so that the MMU notifier is only removedafter the closing of the last remaining VMA.Finally, use an atomic to prevent inadvertent gntdev mapping re-use,instead of using the map->live_grants atomic counter and/or the map->vmapointer (the latter of which is now removed). This prevents theuserspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over thesame address range as a previously set up gntdev mapping. This scenariocan be summarized with the following call-trace, which was valid priorto this commit: mmap gntdev_mmap mmap (repeat mmap with MAP_FIXED over the same address range) gntdev_invalidate unmap_grant_pages (sets 'being_removed' entries to true) gnttab_unmap_refs_async unmap_single_vma gntdev_mmap (maps the shared pages again) munmap gntdev_invalidate unmap_grant_pages (no-op because 'being_removed' entries are true) unmap_single_vma (For PV domains, Xen reports that a granted page is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIG_DEBUG)The fix for this last scenario could be worth its own commit, but weopted for a single commit, because removing the gntdev_grant_mapstructure's vma field requires guarding the entry to gntdev_mmap(), andthe live_grants atomic counter is not sufficient on its own to preventthe mmap() over a pre-existing mapping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/mad: Don't call to function that might sleep while in atomic contextTracepoints are not allowed to sleep, as such the following splat isgenerated due to call to ib_query_pkey() in atomic context.WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Make sure "ib_port" is valid when access sysfs nodeThe "ib_port" structure must be set before adding the sysfs kobject,and reset after removing it, otherwise it may crash when accessingthe sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mounttime".The first patch fixes a bug reported by syzbot, and the second one fixesthe remaining bug of the same kind. Although they are triggered by thesame super block data anomaly, I divided it into the above two because thedetails of the issues and how to fix it are different.Both are required to eliminate the shift-out-of-bounds issues at mounttime.This patch (of 2):If the block size exponent information written in an on-disk superblock iscorrupted, nilfs_sb2_bad_offset helper function can triggershift-out-of-bounds warning followed by a kernel panic (if panic_on_warnis set): shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline] nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523 init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577 nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317 ...In addition, since nilfs_sb2_bad_offset() performs multiplication withoutconsidering the upper bound, the computation may overflow if the disklayout parameters are not normal.This fixes these issues by inserting preliminary sanity checks for thoseparameters and by converting the comparison from one involvingmultiplication and left bit-shifting to one using division and rightbit-shifting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()If device_register() fails in cxl_register_afu|adapter(), the deviceis not added, device_unregister() can not be called in the error path,otherwise it will cause a null-ptr-deref because of removing not addeddevice.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential memory leaksWhen the driver hits -ENOMEM at allocating a URB or a buffer, itaborts and goes to the error path that releases the all previouslyallocated resources. However, when -ENOMEM hits at the middle of thesync EP URB allocation loop, the partially allocated URBs might beleft without released, because ep->nurbs is still zero at that point.Fix it by setting ep->nurbs at first, so that the error handler loopsover the full URB list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crashWhen CPU 0 is offline and intel_powerclamp is used to injectidle, it generates kernel BUG:BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687caller is debug_smp_processor_id+0x17/0x20CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57Call Trace:dump_stack_lvl+0x49/0x63dump_stack+0x10/0x16check_preemption_disabled+0xdd/0xe0debug_smp_processor_id+0x17/0x20powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]......Here CPU 0 is the control CPU by default and changed to the current CPU,if CPU 0 offlined. This check has to be performed under cpus_read_lock(),hence the above warning.Use get_cpu() instead of smp_processor_id() to avoid this BUG.[ rjw: Subject edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for dcoda_iram_allocAs the coda_iram_alloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: lpddr2_nvm: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(add_range) invoked,if platform_get_resource() returns NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas: avoid scheduling in rtas_os_term()It's unsafe to use rtas_busy_delay() to handle a busy status fromthe ibm,os-term RTAS function in rtas_os_term():Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000bBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 2, expected: 0CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9Call Trace:[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200Use rtas_busy_delay_time() instead, which signals without side effectswhether to attempt the ibm,os-term RTAS call again.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix pci device refcount leak in ppr_notifier()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it before returning from ppr_notifier()to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for kmallocAs the kmalloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/fonts: fix undefined behavior in bit shift for get_default_fontShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20left shift of 1 by 31 places cannot be represented in type 'int' dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix potential memory leak in ext4_fc_record_regions()As krealloc may return NULL, in this case 'state->fc_regions' may not befreed by krealloc, but 'state->fc_regions' already set NULL. Then willlead to 'state->fc_regions' memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_hid: fix refcount leak on error pathWhen failing to allocate report_desc, opts->refcnt has already beenincremented so it needs to be decremented to avoid leaving the optionsstructure permanently locked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue()If construction of the array of work queues to handle hpd_rx_irq offloadwork fails, we need to unwind. Destroy all the created workqueues andthe allocated memory for the hpd_rx_irq_offload_work_queue struct array.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix invalid derefence of sb_lvbptrI experience issues when putting a lkbsb on the stack and have sb_lvbptrfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crashwith the following kernel message, the dangled pointer is here0xdeadbeef as example:[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef[ 102.749320] #PF: supervisor read access in kernel mode[ 102.749323] #PF: error_code(0x0000) - not-present page[ 102.749325] PGD 0 P4D 0[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 102.749379] PKRU: 55555554[ 102.749381] Call Trace:[ 102.749382] [ 102.749383] ? send_args+0xb2/0xd0[ 102.749389] send_common+0xb7/0xd0[ 102.749395] _unlock_lock+0x2c/0x90[ 102.749400] unlock_lock.isra.56+0x62/0xa0[ 102.749405] dlm_unlock+0x21e/0x330[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture][ 102.749419] ? preempt_count_sub+0xba/0x100[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture][ 102.786186] kthread+0x10a/0x130[ 102.786581] ? kthread_complete_and_exit+0x20/0x20[ 102.787156] ret_from_fork+0x22/0x30[ 102.787588] [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw[ 102.792536] CR2: 00000000deadbeef[ 102.792930] ---[ end trace 0000000000000000 ]---This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflagsis set when copying the lvbptr array instead of if it's just null whichfixes for me the issue.I think this patch can fix other dlm users as well, depending how theyhandle the init, freeing memory handling of sb_lvbptr and don't setDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be ahidden issue all the time. However with checking on DLM_LKF_VALBLK theuser always need to provide a sb_lvbptr non-null value. There might bemore intelligent handling between per ls lvblen, DLM_LKF_VALBLK andnon-null to report the user the way how DLM API is used is wrong but canbe added for later, this will only fix the current behaviour.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()As comment of pci_get_class() says, it returns a pci_device with itsrefcount increased and decreased the refcount for the input parameter@from if it is not NULL.If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, weneed to call pci_dev_put() to decrease the refcount. Add the missingpci_dev_put() to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()is not freed after the call, so it leads to memory leak.The method results in ACPI buffer is not used, so just pass NULL towmi_evaluate_method() which fixes the memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: rockchip: Fix memory leak in rockchip_clk_register_pll()If clk_register() fails, @pll->rate_table may have allocated memory bykmemdup(), so it needs to be freed, otherwise will cause memory leakissue, this patch fixes it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Check return value after calling platform_get_resource()platform_get_resource() may return NULL pointer, we need check itsreturn value to avoid null-ptr-deref in resource_size().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe()The fsl_pamu_probe() returns directly when create_csd() failed, leavingirq and memories unreleased.Fix by jumping to error if create_csd() returns error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dp: fix memory corruption with too many bridgesAdd the missing sanity check on the bridge counter to avoid corruptingdata beyond the fixed-sized bridge array in case there are ever morethan eight bridges.Patchwork: https://patchwork.freedesktop.org/patch/502664/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix size validation for non-exclusive domains (v4)Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for therequested memory exists, else we get a kernel oops when dereferencing "man".v2: Make the patch standalone, i.e. not dependent on local patches.v3: Preserve old behaviour and just check that the manager pointer is not NULL.v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix memory leakageThis patch fixes potential memory leakage and seg faultin _gpuvm_import_dmabuf() function
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:test_firmware: fix memory leak in test_firmware_init()When misc_register() failed in test_firmware_init(), the memory pointedby test_fw_config->name is not released. The memory leak information isas follows:unreferenced object 0xffff88810a34cb00 (size 32): comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s) hex dump (first 32 bytes): 74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... backtrace: [] __kmalloc_node_track_caller+0x4b/0xc0 [] kstrndup+0x46/0xc0 [] __test_firmware_config_init+0x29/0x380 [test_firmware] [] 0xffffffffa040f068 [] do_one_initcall+0x141/0x780 [] do_init_module+0x1c3/0x630 [] load_module+0x623e/0x76a0 [] __do_sys_finit_module+0x181/0x240 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()Our syzkaller report a null pointer dereference, root cause isfollowing:__blk_mq_alloc_map_and_rqs set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs blk_mq_alloc_map_and_rqs blk_mq_alloc_rqs // failed due to oom alloc_pages_node // set->tags[hctx_idx] is still NULL blk_mq_free_rqs drv_tags = set->tags[hctx_idx]; // null pointer dereference is triggered blk_mq_clear_rq_mapping(drv_tags, ...)This is because commit 63064be150e4 ("blk-mq:Add blk_mq_alloc_map_and_rqs()") merged the two steps:1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])into one step:set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()Since tags is not initialized yet in this case, fix the problem bychecking if tags is NULL pointer in blk_mq_clear_rq_mapping().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,sas_rphy_free() needs be called to free the resource allocated insas_end_device_alloc(). Otherwise a kernel crash will happen:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : device_del+0x54/0x3d0lr : device_del+0x37c/0x3d0Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas]Because transport_add_device() is not called when sas_rphy_add() fails, thedevice is not added. When sas_rphy_remove() is subsequently called toremove the device in the remove() path, a NULL pointer dereference happens.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Use last transaction's pmd->root when commit failedRecently we found a softlock up problem in dm thin pool btree lookupcode due to corrupted metadata: Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x9c/0xd3 panic+0x35d/0x6b9 watchdog_timer_fn.cold+0x16/0x25 __run_hrtimer+0xa2/0x2d0 RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio] __bufio_new+0x11f/0x4f0 [dm_bufio] new_read+0xa3/0x1e0 [dm_bufio] dm_bm_read_lock+0x33/0xd0 [dm_persistent_data] ro_step+0x63/0x100 [dm_persistent_data] btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data] dm_btree_lookup+0x16f/0x210 [dm_persistent_data] dm_thin_find_block+0x12c/0x210 [dm_thin_pool] __process_bio_read_only+0xc5/0x400 [dm_thin_pool] process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool] process_one_work+0x3c5/0x730Following process may generate a broken btree mixed with fresh andstale btree nodes, which could get dm thin trapped in an infinite loopwhile looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. process_bio_read_only dm_thin_find_block __find_block dm_btree_lookup(pmd->root)The pmd->root points to a broken btree, Y may contain stale nodepointing to any block, for example X, which gets dm thin trapped intoa dead loop while looking up Z.Fix this by setting pmd->root in __open_metadata(), so that dm thinwill use the last transaction's pmd->root if commit failed.Fetch a reproducer in [Link].Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential null-deref in dm_resume[Why]Fixing smatch error:dm_resume() error: we previously assumed 'aconnector->dc_link' could be null[How]Check if dc_link null at the beginning of the loop,so further checks can be dropped.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' willnot be freed through rpi_firmware_delete(), fix this leak by callingkfree() in the error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix mr->map double freerxe_mr_cleanup() which tries to free mr->map again will be called whenrxe_mr_init_user() fails: CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x5d panic+0x19e/0x349 end_report.part.0+0x54/0x7c kasan_report.cold+0xa/0xf rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe] __rxe_cleanup+0x10a/0x1e0 [rdma_rxe] rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe] ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs]This issue was firstly exposed since commit b18c7da63fcb ("RDMA/rxe: Fixmemory leak in error path code") and then we fixed it in commit8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") but thisfix was reverted together at last by commit 1e75550648da (Revert"RDMA/rxe: Create duplicate mapping tables for FMRs")Simply let rxe_mr_cleanup() always handle freeing the mr->map once it issuccessfully allocated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()xhci_alloc_stream_info() allocates stream context array for stream_info->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,stream_info->stream_ctx_array is not released, which will lead to amemory leak.We can fix it by releasing the stream_info->stream_ctx_array withxhci_free_stream_ctx() on the error path to avoid the potential memoryleak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:r6040: Fix kmemleak in probe and removeThere is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ...The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problemThe root cause is traced to the phy_device is not disconnected whenremoves one r6040 device in r6040_remove_one() or on error handling pathafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernetdevice is connected to the first PHY device of mii_bus, in order tonotify the connected driver when the link status changes, which is thedefault behavior of the PHY infrastructure to handle everything.Therefore the phy_device should be disconnected when removes one r6040device or on error handling path.Fix it by adding phy_disconnect() when removes one r6040 device or onerror handling path after r6040_mii probed successfully.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninititialized value in 'ext4_evict_inode'Syzbot found the following issue:=====================================================BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0 fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022=====================================================Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failedbefore set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' whichwill lead to access uninit-value.To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadataFollowing concurrent processes: P1(drop cache) P2(kworker)drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block v down_read(&pmd->root_lock) --> ABBA deadlock, which triggers hung task:[ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.[ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2[ 76.978534] Workqueue: dm-thin do_worker[ 76.978552] Call Trace:[ 76.978564] __schedule+0x6ba/0x10f0[ 76.978582] schedule+0x9d/0x1e0[ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0[ 76.978600] down_write+0xec/0x110[ 76.978607] unregister_shrinker+0x2c/0xf0[ 76.978616] dm_bufio_client_destroy+0x116/0x3d0[ 76.978625] dm_block_manager_destroy+0x19/0x40[ 76.978629] __destroy_persistent_data_objects+0x5e/0x70[ 76.978636] dm_pool_abort_metadata+0x8e/0x100[ 76.978643] metadata_operation_failed+0x86/0x110[ 76.978649] commit+0x6a/0x230[ 76.978655] do_worker+0xc6e/0xd90[ 76.978702] process_one_work+0x269/0x630[ 76.978714] worker_thread+0x266/0x630[ 76.978730] kthread+0x151/0x1b0[ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.[ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459[ 76.982128] Call Trace:[ 76.982139] __schedule+0x6ba/0x10f0[ 76.982155] schedule+0x9d/0x1e0[ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910[ 76.982173] down_read+0x84/0x170[ 76.982177] dm_thin_find_block+0x4c/0xd0[ 76.982183] thin_map+0x201/0x3d0[ 76.982188] __map_bio+0x5b/0x350[ 76.982195] dm_submit_bio+0x2b6/0x930[ 76.982202] __submit_bio+0x123/0x2d0[ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0[ 76.982222] submit_bio_noacct+0x389/0x770[ 76.982227] submit_bio+0x50/0xc0[ 76.982232] submit_bh_wbc+0x15e/0x230[ 76.982238] submit_bh+0x14/0x20[ 76.982241] ext4_read_bh_nowait+0xc5/0x130[ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60[ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0[ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0[ 76.982263] ext4_discard_preallocations+0x45d/0x830[ 76.982274] ext4_clear_inode+0x48/0xf0[ 76.982280] ext4_evict_inode+0xcf/0xc70[ 76.982285] evict+0x119/0x2b0[ 76.982290] dispose_list+0x43/0xa0[ 76.982294] prune_icache_sb+0x64/0x90[ 76.982298] super_cache_scan+0x155/0x210[ 76.982303] do_shrink_slab+0x19e/0x4e0[ 76.982310] shrink_slab+0x2bd/0x450[ 76.982317] drop_slab+0xcc/0x1a0[ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0[ 76.982327] proc_sys_call_handler+0x1bc/0x300[ 76.982331] proc_sys_write+0x17/0x20[ 76.982334] vfs_write+0x3d3/0x570[ 76.982342] ksys_write+0x73/0x160[ 76.982347] __x64_sys_write+0x1e/0x30[ 76.982352] do_syscall_64+0x35/0x80[ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcdFunct---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()This patch fixes a shift-out-of-bounds in brcmfmac that occurs inBIT(chiprev) when a 'chiprev' provided by the device is too large.It should also not be equal to or greater than BITS_PER_TYPE(u32)as we do bitwise AND with a u32 variable and BIT(chiprev). The patchadds a check that makes the function return NULL if that is the case.Note that the NULL case is later handled by the bus-specific caller,brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.Found by a modified version of syzkaller.UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.cshift exponent 151055786 is too large for 64-bit type 'long unsigned int'CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? pr---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'When generate a synthetic event with many params and then create a traceaction for it [1], kernel panic happened [2].It is because that in trace_action_create() 'data->n_params' is up toSYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'keeps indices into array 'hist_data->var_refs' for each synthetic eventparam, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX(current value is 16), so out-of-bound write happened when 'data->n_params'more than 16. In this case, 'data->match_data.event' is overwritten andeventually cause the panic.To solve the issue, adjust the length of 'data->var_ref_idx' to beSYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.[1] # cd /sys/kernel/tracing/ # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\int v63" >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> \events/sched/sched_waking/trigger # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger[2]BUG: unable to handle page fault for address: ffff91c900000000PGD 61001067 P4D 61001067 PUD 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:strcmp+0xc/0x30Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 eec3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 1407 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0Call Trace: __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f1d1d0cf077Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1efa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142R---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: Fix potential null-ptr-deref due to drmm_mode_config_init()drmm_mode_config_init() will call drm_mode_create_standard_properties()and won't check the ret value. When drm_mode_create_standard_properties()failed due to alloc, property will be a NULL pointer and may causes thenull-ptr-deref. Fix the null-ptr-deref by adding the ret value check.Found null-ptr-deref while testing insert module bochs:general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]CPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]Call Trace: __drm_connector_init+0xb6c/0x1100 [drm] bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs] pci_device_probe+0x17d/0x340 really_probe+0x1db/0x5d0 __driver_probe_device+0x1e7/0x250 driver_probe_device+0x4a/0x120 __driver_attach+0xcd/0x2c0 bus_for_each_dev+0x11a/0x1b0 bus_add_driver+0x3d7/0x500 driver_register+0x18e/0x320 do_one_initcall+0xc4/0x3e0 do_init_module+0x1b4/0x630 load_module+0x5dca/0x7230 __do_sys_finit_module+0x100/0x170 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7ff65af9f839
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: scu: fix memleak on platform_device_add() failsNo error handling is performed when platform_device_add()fails. Add error processing before return, and modifiedthe return value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: explicitly remove aggregate driver at module unload timeBecause component_master_del wasn't being called when unloading themeson_drm module, the aggregate device would linger forever in the globalaggregate_devices list. That means when unloading and reloading themeson_dw_hdmi module, component_add would call intotry_to_bring_up_aggregate_device and find the unbound meson_drm aggregatedevice.This would in turn dereference some of the aggregate_device's structentries which point to memory automatically freed by the devres API whenunbinding the aggregate device from meson_drv_unbind, and trigger anuse-after-free bug:[ +0.000014] =============================================================[ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500[ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536[ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1[ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT)[ +0.000008] Call trace:[ +0.000005] dump_backtrace+0x1ec/0x280[ +0.000011] show_stack+0x24/0x80[ +0.000007] dump_stack_lvl+0x98/0xd4[ +0.000010] print_address_description.constprop.0+0x80/0x520[ +0.000011] print_report+0x128/0x260[ +0.000007] kasan_report+0xb8/0xfc[ +0.000007] __asan_report_load8_noabort+0x3c/0x50[ +0.000009] find_components+0x468/0x500[ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390[ +0.000009] __component_add+0x1dc/0x49c[ +0.000009] component_add+0x20/0x30[ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi][ +0.000013] platform_probe+0xd0/0x220[ +0.000008] really_probe+0x3ac/0xa80[ +0.000008] __driver_probe_device+0x1f8/0x400[ +0.000008] driver_probe_device+0x68/0x1b0[ +0.000008] __driver_attach+0x20c/0x480[ +0.000009] bus_for_each_dev+0x114/0x1b0[ +0.000007] driver_attach+0x48/0x64[ +0.000009] bus_add_driver+0x390/0x564[ +0.000007] driver_register+0x1a8/0x3e4[ +0.000009] __platform_driver_register+0x6c/0x94[ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi][ +0.000014] do_one_initcall+0xc4/0x2b0[ +0.000008] do_init_module+0x154/0x570[ +0.000010] load_module+0x1a78/0x1ea4[ +0.000008] __do_sys_init_module+0x184/0x1cc[ +0.000008] __arm64_sys_init_module+0x78/0xb0[ +0.000008] invoke_syscall+0x74/0x260[ +0.000008] el0_svc_common.constprop.0+0xcc/0x260[ +0.000009] do_el0_svc+0x50/0x70[ +0.000008] el0_svc+0x68/0x1a0[ +0.000009] el0t_64_sync_handler+0x11c/0x150[ +0.000009] el0t_64_sync+0x18c/0x190[ +0.000014] Allocated by task 902:[ +0.000007] kasan_save_stack+0x2c/0x5c[ +0.000009] __kasan_kmalloc+0x90/0xd0[ +0.000007] __kmalloc_node+0x240/0x580[ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac[ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0[ +0.000008] kmem_cache_alloc_node+0x1d0/0x490[ +0.000009] __alloc_skb+0x1d4/0x310[ +0.000010] alloc_skb_with_frags+0x8c/0x620[ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0[ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0[ +0.000010] sock_sendmsg+0xcc/0x110[ +0.000007] sock_write_iter+0x1d0/0x304[ +0.000008] new_sync_write+0x364/0x460[ +0.000007] vfs_write+0x420/0x5ac[ +0.000008] ksys_write+0x19c/0x1f0[ +0.000008] __arm64_sys_write+0x78/0xb0[ +0.000007] invoke_syscall+0x74/0x260[ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260[ +0.000009] do_el0_svc+0x50/0x70[ +0.000007] el0_svc+0x68/0x1a0[ +0.000008] el0t_64_sync_handler+0x11c/0x150[ +0.000008] el0t_64_sync+0x18c/0x190[ +0.000013] Freed by task 2509:[ +0.000008] kasan_save_stack+0x2c/0x5c[ +0.000007] kasan_set_track+0x2c/0x40[ +0.000008] kasan_set_free_info+0x28/0x50[ +0.000008] ____kasan_slab_free+0x128/0x1d4[ +0.000008] __kasan_slab_free+0x18/0x24[ +0.000007] slab_free_freelist_hook+0x108/0x230[ +0.000010] ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: acpi: Call acpi_put_table() to fix memory leakThe start and length of the event log area are obtained fromTPM2 or TCPA table, so we call acpi_get_table() to get theACPI information, but the acpi_get_table() should be coupled withacpi_put_table() to release the ACPI memory, add the acpi_put_table()properly to fix the memory leak.While we are at it, remove the redundant empty line at theend of the tpm_read_log_acpi().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/netiucv: Fix return type of netiucv_tx()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netiucv_tx, ^~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.Additionally, while in the area, remove a comment block that is nolonger relevant.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_hid: fix f_hidg lifetime vs cdevThe embedded struct cdev does not have its lifetime correctly tied tothe enclosing struct f_hidg, so there is a use-after-free if /dev/hidgNis held open while the gadget is deleted.This can readily be replicated with libusbgx's example programs (forconciseness - operating directly via configfs is equivalent): gadget-hid exec 3<> /dev/hidg0 gadget-vid-pid-remove exec 3<&-Pull the existing device up in to struct f_hidg and make use of thecdev_device_{add,del}() helpers. This changes the lifetime of thedevice object to match struct f_hidg, but note that it is still addedand deleted at the same time.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link()The of_get_next_child() returns a node with refcount incremented, anddecrements the refcount of prev. So in the error path of the while loop,of_node_put() needs be called for cpu_ep.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/omap: dss: Fix refcount leak bugsIn dss_init_ports() and __dss_uninit_ports(), we should callof_node_put() for the reference returned by of_graph_get_port_by_id()in fail path or when it is not used anymore.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netsec: fix error handling in netsec_register_mdio()If phy_device_register() fails, phy_device_free() need be called toput refcount, so memory of phy device and device name can be freedin callback function.If get_phy_device() fails, mdiobus_unregister() need be called,or it will cause warning in mdiobus_free() and kobject is leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gud: Fix UBSAN warningUBSAN complains about invalid value for bool:[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device[ 101.213426] usbcore: registered new interface driver gud[ 101.989431] ================================================================================[ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9[ 101.989447] load of value 121 is not a valid value for type '_Bool'[ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3[ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018[ 101.989459] Workqueue: events_long gud_flush_work [gud][ 101.989471] Call Trace:[ 101.989474] [ 101.989479] dump_stack_lvl+0x49/0x5f[ 101.989488] dump_stack+0x10/0x12[ 101.989493] ubsan_epilogue+0x9/0x3b[ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49[ 101.989504] dma_buf_vmap.cold+0x38/0x3d[ 101.989511] ? find_busiest_group+0x48/0x300[ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper][ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper][ 101.989535] drm_gem_vmap+0x26/0x60 [drm][ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper][ 101.989630] gud_prep_flush+0xc1/0x710 [gud][ 101.989639] ? _raw_spin_lock+0x17/0x40[ 101.989648] gud_flush_work+0x1e0/0x430 [gud][ 101.989653] ? __switch_to+0x11d/0x470[ 101.989664] process_one_work+0x21f/0x3f0[ 101.989673] worker_thread+0x200/0x3e0[ 101.989679] ? rescuer_thread+0x390/0x390[ 101.989684] kthread+0xfd/0x130[ 101.989690] ? kthread_complete_and_exit+0x20/0x20[ 101.989696] ret_from_fork+0x22/0x30[ 101.989706] [ 101.989708] ================================================================================The source of this warning is in iosys_map_clear() called fromdma_buf_vmap(). It conditionally sets values based on map->is_iomem. Theiosys_map variables are allocated uninitialized on the stack leading to->is_iomem having all kinds of values and not only 0/1.Fix this by zeroing the iosys_map variables.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: perf: marvell_cn10k: Fix hotplug callback leak in tad_pmu_init()tad_pmu_init() won't remove the callback added by cpuhp_setup_state_multi()when platform_driver_register() failed. Remove the callback bycpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()cw_bat_probe() calls create_singlethread_workqueue() and not checked theret value, which may return NULL. And a null-ptr-deref may happen:cw_bat_probe() create_singlethread_workqueue() # failed, cw_bat->wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: associate skb with a device at txSyzkaller triggered flow dissector warning with the following:r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0[ 9.485929] skb_get_poff+0x53/0xa0[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20[ 9.485944] ? ppp_send_frame+0xc2/0x5b0[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0[ 9.485968] ? ppp_xmit_process+0x5b/0xb0[ 9.485974] ? ppp_write+0x12a/0x190[ 9.485981] ? do_iter_write+0x18e/0x2d0[ 9.485987] ? __import_iovec+0x30/0x130[ 9.485997] ? do_pwritev+0x1b6/0x240[ 9.486016] ? trace_hardirqs_on+0x47/0x50[ 9.486023] ? __x64_sys_pwritev+0x24/0x30[ 9.486026] ? do_syscall_64+0x3d/0x80[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcdFlow dissector tries to find skb net namespace either via deviceor via socket. Neigher is set in ppp_send_frame, so let's manuallyuse ppp->dev.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], forcommit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication inrds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a sectionprotected by lock_sock() without realizing that rds_send_xmit() might calllock_sock().We don't need to protect cancel_delayed_work_sync() using lock_sock(), foreven if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete,retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UPbit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix pci device refcount leakAs comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put().So before returning from amdgpu_device_resume|suspend_display_audio(),pci_dev_put() is called to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: efct: Fix possible memleak in efct_device_init()In efct_device_init(), when efct_scsi_reg_fc_transport() fails,efct_scsi_tgt_driver_exit() is not called to release memory forefct_scsi_tgt_driver_init() and causes memleak:unreferenced object 0xffff8881020ce000 (size 2048): comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s) backtrace: [<0000000021a1ef1b>] kmalloc_trace+0x27/0x110 [<000000004c3ed51c>] target_register_template+0x4fd/0x7b0 [target_core_mod] [<00000000f3393296>] efct_scsi_tgt_driver_init+0x18/0x50 [efct] [<00000000115de533>] 0xffffffffc0d90011 [<00000000d608f646>] do_one_initcall+0xd0/0x4e0 [<0000000067828cf1>] do_init_module+0x1cc/0x6a0 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/lcs: Fix return type of lcs_start_xmit()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: silence the warning when evicting inode with dioread_nolockWhen evicting an inode with default dioread_nolock, it could be raced bythe unwritten extents converting kworker after writeback some newallocated dirty blocks. It convert unwritten extents to written, theextents could be merged to upper level and free extent blocks, so itcould mark the inode dirty again even this inode has been markedI_FREEING. But the inode->i_io_list check and warning inext4_evict_inode() missing this corner case. Fortunately,ext4_evict_inode() will wait all extents converting finished before thischeck, so it will not lead to inode use-after-free problem, every thingis OK besides this warning. The WARN_ON_ONCE was originally designedfor finding inode use-after-free issues in advance, but if we addcurrent dioread_nolock case in, it will become not quite useful, so fixthis warning by just remove this check. ====== WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227 ext4_evict_inode+0x875/0xc60 ... RIP: 0010:ext4_evict_inode+0x875/0xc60 ... Call Trace: evict+0x11c/0x2b0 iput+0x236/0x3a0 do_unlinkat+0x1b4/0x490 __x64_sys_unlinkat+0x4c/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fa933c1115b ======rm kworker ext4_end_io_end()vfs_unlink() ext4_unlink() ext4_convert_unwritten_io_end_vec() ext4_convert_unwritten_extents() ext4_map_blocks() ext4_ext_map_blocks() ext4_ext_try_to_merge_up() __mark_inode_dirty() check !I_FREEING locked_inode_to_wb_and_lock_list() iput() iput_final() evict() ext4_evict_inode() truncate_inode_pages_final() //wait release io_end inode_io_list_move_locked() ext4_release_io_end() trigger WARN_ON_ONCE()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: akcipher - default implementation for setting a private keyChanges from v1: * removed the default implementation from set_pub_key: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public keyMany akcipher implementations (like ECDSA) support only signatureverifications, so they don't have all callbacks defined.Commit 78a0324f4a53 ("crypto: akcipher - default implementations forrequest callbacks") introduced default callbacks for sign/verifyoperations, which just return an error code.However, these are not enough, because before calling sign the caller wouldlikely call set_priv_key first on the instantiated transform (as thein-kernel testmgr does). This function does not have a default stub, so thekernel crashes, when trying to set a private key on an akcipher, whichdoesn't support signature generation.I've noticed this, when trying to add a KAT vector for ECDSA signature tothe testmgr.With this patch the testmgr returns an error in dmesg (as it should)instead of crashing the kernel NULL ptr dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: core: Fix memleak in nvmem_register()dev_set_name will alloc memory for nvmem->dev.kobj.name innvmem_register, when nvmem_validate_keepouts failed, nvmem'smemory will be freed and return, but nobody will free memoryfor nvmem->dev.kobj.name, there will be memleak, so movingnvmem_validate_keepouts() after device_register() and letthe device core deal with cleaning name in error cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Disable useless interrupt to avoid kernel panicThere is a hardware bug that the interrupt STMBUF_HALF may be triggeredafter or when disable interrupt.It may led to unexpected kernel panic.And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.So disable them and the unused interrupts.meanwhile clear the interrupt status when disable interrupt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffersyzbot is reporting uninit-value in btrfs_clean_tree_block() [1], forcommit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code")missed that btrfs_set_header_generation() in btrfs_init_new_buffer() mustnot be moved to after clean_tree_block() because clean_tree_block() iscalling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs:Fix extent_buffer usage when nodesize != leafsize").Since memzero_extent_buffer() will reset "struct btrfs_header" part, wecan't move btrfs_set_header_generation() to before memzero_extent_buffer().Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()Running rcutorture with non-zero fqs_duration module parameter in akernel built with CONFIG_PREEMPTION=y results in the following splat:BUG: using __this_cpu_read() in preemptible [00000000]code: rcu_torture_fqs/398caller is __this_cpu_preempt_check+0x13/0x20CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+Call Trace:dump_stack_lvl+0x5b/0x86dump_stack+0x10/0x16check_preemption_disabled+0xe5/0xf0__this_cpu_preempt_check+0x13/0x20rcu_force_quiescent_state.part.0+0x1c/0x170rcu_force_quiescent_state+0x1e/0x30rcu_torture_fqs+0xca/0x160? rcu_torture_boost+0x430/0x430kthread+0x192/0x1d0? kthread_complete_and_exit+0x30/0x30ret_from_fork+0x22/0x30The problem is that rcu_force_quiescent_state() uses __this_cpu_read()in preemptible code instead of the proper raw_cpu_read(). This committherefore changes __this_cpu_read() to raw_cpu_read().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-mfc: Clear workbit to handle error conditionDuring error on CLOSE_INSTANCE command, ctx_work_bits was not gettingcleared. During consequent mfc execution NULL pointer dereferencing ofthis context led to kernel panic. This patch fixes this issue by makingsure to clear ctx_work_bits always.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: devices: fix missing put_device in mport_cdev_openWhen kfifo_alloc fails, the refcount of chdev->dev is left incremental. We should use put_device(&chdev->dev) to decrease the ref count ofchdev->dev to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix missing unmap if z_erofs_get_extent_compressedlen() failsOtherwise, meta buffers could be leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: mcb: fix resource leak in mcb_probe()When probe hook function failed in mcb_probe(), it doesn't put the device.Compiled test only.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()dmc620_pmu_init() won't remove the callback added bycpuhp_setup_state_multi() when platform_driver_register() failed. Removethe callback by cpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: virtual_ncidev: Fix memory leak in virtual_nci_send()skb should be free in virtual_nci_send(), otherwise kmemleak will reportmemleak.Steps for reproduction (simulated in qemu): cd tools/testing/selftests/nci make ./nci_devBUG: memory leakunreferenced object 0xffff888107588000 (size 208): comm "nci_dev", pid 206, jiffies 4294945376 (age 368.248s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000008d94c8fd>] __alloc_skb+0x1da/0x290 [<00000000278bc7f8>] nci_send_cmd+0xa3/0x350 [<0000000081256a22>] nci_reset_req+0x6b/0xa0 [<000000009e721112>] __nci_request+0x90/0x250 [<000000005d556e59>] nci_dev_up+0x217/0x5b0 [<00000000e618ce62>] nfc_dev_up+0x114/0x220 [<00000000981e226b>] nfc_genl_dev_up+0x94/0xe0 [<000000009bb03517>] genl_family_rcv_msg_doit.isra.14+0x228/0x2d0 [<00000000b7f8c101>] genl_rcv_msg+0x35c/0x640 [<00000000c94075ff>] netlink_rcv_skb+0x11e/0x350 [<00000000440cfb1e>] genl_rcv+0x24/0x40 [<0000000062593b40>] netlink_unicast+0x43f/0x640 [<000000001d0b13cc>] netlink_sendmsg+0x73a/0xbf0 [<000000003272487f>] __sys_sendto+0x324/0x370 [<00000000ef9f1747>] __x64_sys_sendto+0xdd/0x1b0 [<000000001e437841>] do_syscall_64+0x3f/0x90
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: rio: fix possible name leak in rio_register_mport()If device_register() returns error, the name allocated by dev_set_name()need be freed. It should use put_device() to give up the reference in theerror path, so that the name can be freed in kobject_cleanup(), andlist_del() is called to delete the port from rio_mports.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix a signed-integer-overflow bug in tcp_add_backlog()The type of sk_rcvbuf and sk_sndbuf in struct sock is int, andin tcp_add_backlog(), the variable limit is caculated by addingsk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max valueof int and overflow. This patch reduces the limit budget byhalving the sndbuf to solve this issue since ACK packets are muchsmaller than the payload.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Fix qmi_msg_handler data structure initializationqmi_msg_handler is required to be null terminated by QMI module.There might be a case where a handler for a msg id is not present in thehandlers array which can lead to infinite loop while searching the handlerand therefore out of bound access in qmi_invoke_handler().Hence update the initialization in qmi_msg_handler data structure.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 willbe NULL, and strcmp() will cause null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: broadcom: bcm4908_enet: update TX stats after actual transmissionQueueing packets doesn't guarantee their transmission. Update TX statsafter hardware confirms consuming submitted data.This also fixes a possible race and NULL dereference.bcm4908_enet_start_xmit() could try to access skb after freeing it inthe bcm4908_enet_poll_tx().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: qcom: q6v5: Fix potential null-ptr-deref in q6v5_wcss_init_mmio()q6v5_wcss_init_mmio() will call platform_get_resource_byname() that mayfail and return NULL. devm_ioremap() will use res->start as input, whichmay causes null-ptr-deref. Check the ret value ofplatform_get_resource_byname() to avoid the null-ptr-deref.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: Fix UAF in dm_integrity_dtr()Dm_integrity also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in dm_integrity_dtr().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix possible store tearing in neigh_periodic_work()While looking at a related syzbot report involving neigh_periodic_work(),I found that I forgot to add an annotation when deleting anRCU protected item from a list.Readers use rcu_deference(*np), we need to use eitherrcu_assign_pointer() or WRITE_ONCE() on writer sideto prevent store tearing.I use rcu_assign_pointer() to have lockdep support,this was the choice made in neigh_flush_dev().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()Including the transhdrlen in length is a problem when the packet ispartially filled (e.g. something like send(MSG_MORE) happened previously)when appending to an IPv4 or IPv6 packet as we don't want to repeat thetransport header or account for it twice. This can happen under somecircumstances, such as splicing into an L2TP socket.The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800that occurs when MSG_SPLICE_PAGES is used to append more data to an alreadypartially occupied skbuff. The warning occurs when 'copy' is larger thanthe amount of data in the message iterator. This is because the requestedlength includes the transport header length when it shouldn't. This can betriggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024);Fix this by only adding transhdrlen into the length if the write queue isempty in l2tp_ip6_sendmsg(), analogously to how UDP does things.l2tp_ip_sendmsg() looks like it won't suffer from this problem as it buildsthe UDP packet itself.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: prevent deadlock by changing j1939_socks_lock to rwlockThe following 3 locks would race against each other, causing thedeadlock situation in the Syzbot bug report:- j1939_socks_lock- active_session_list_lock- sk_session_queue_lockA reasonable fix is to change j1939_socks_lock to an rwlock, since inthe rare situations where a write lock is required for the linked listthat j1939_socks_lock is protecting, the code does not attempt toacquire any more locks. This would break the circular lock dependency,where, for example, the current thread already locks j1939_socks_lockand attempts to acquire sk_session_queue_lock, and at the same time,another thread attempts to acquire j1939_socks_lock while holdingsk_session_queue_lock.NOTE: This patch along does not fix the unregister_netdevice bugreported by Syzbot; instead, it solves a deadlock situation to preparefor one or more further patches to actually fix the Syzbot bug, whichappears to be a reference counting problem within the j1939 codebase.[mkl: remove unrelated newline change]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Unmap the surface before resetting it on a plane stateSwitch to a new plane state requires unreferencing of all held surfaces.In the work required for mob cursors the mapped surfaces started beingcached but the variable indicating whether the surface is currentlymapped was not being reset. This leads to crashes as the duplicatedstate, incorrectly, indicates the that surface is mapped even whenno surface is present. That's because after unreferencing the surfaceit's perfectly possible for the plane to be backed by a bo instead of asurface.Reset the surface mapped flag when unreferencing the plane state surfaceto fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:Oops: 0000 [#1] PREEMPT SMP PTICPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7f1e93f279edCode: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279edRDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine>CR2: 0000000000000028---[ end trace 0000000000000000 ]---RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600RBP: ffff969d4143---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newerPrior to LLVM 15.0.0, LLVM's integrated assembler would incorrectlybyte-swap NOP when compiling for big-endian, and the resulting series ofbytes happened to match the encoding of FNMADD S21, S30, S0, S0.This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")Prior to that commit, the kernel would always enable the use of FPSIMDearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage ofFNMADD within the kernel was not detected, but could result in thecorruption of user or kernel FPSIMD state.After that commit, the instructions happen to trap during boot prior toFPSIMD being detected and enabled, e.g.| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : __pi_strcmp+0x1c/0x150| lr : populate_properties+0xe4/0x254| sp : ffffd014173d3ad0| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8| Kernel panic - not syncing: Unhandled exception| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| Call trace:| dump_backtrace+0xec/0x108| show_stack+0x18/0x2c| dump_stack_lvl+0x50/0x68| dump_stack+0x18/0x24| panic+0x13c/0x340| el1t_64_irq_handler+0x0/0x1c| el1_abort+0x0/0x5c| el1h_64_sync+0x64/0x68| __pi_strcmp+0x1c/0x150| unflatten_dt_nodes+0x1e8/0x2d8| __unflatten_device_tree+0x5c/0x15c| unflatten_device_tree+0x38/0x50| setup_arch+0x164/0x1e0| start_kernel+0x64/0x38c| __primary_switched+0xbc/0xc4Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which iseither GNU as or LLVM's IAS 15.0.0 and newer, which contains the linkedcommit.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst->flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon't call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&wait->completion), which will causehungtask.The problem comes as following:(padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: support non-r10 register spill/fill to/from stack in precision trackingUse instruction (jump) history to record instructions that performedregister spill/fill to/from stack, regardless if this was done throughread-only r10 register, or any other register after copying r10 into it*and* potentially adjusting offset.To make this work reliably, we push extra per-instruction flags intoinstruction history, encoding stack slot index (spi) and stack framenumber in extra 10 bit flags we take away from prev_idx in instructionhistory. We don't touch idx field for maximum performance, as it'schecked most frequently during backtracking.This change removes basically the last remaining practical limitation ofprecision backtracking logic in BPF verifier. It fixes knowndeficiencies, but also opens up new opportunities to reduce number ofverified states, explored in the subsequent patches.There are only three differences in selftests' BPF object filesaccording to veristat, all in the positive direction (less states).File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)Note, I avoided renaming jmp_history to more generic insn_hist tominimize number of lines changed and potential merge conflicts betweenbpf and bpf-next trees.Notice also cur_hist_entry pointer reset to NULL at the beginning ofinstruction verification loop. This pointer avoids the problem ofrelying on last jump history entry's insn_idx to determine whether wealready have entry for current instruction or not. It can happen that weadded jump history entry because current instruction is_jmp_point(), butalso we need to add instruction flags for stack access. In this case, wedon't want to entries, so we need to reuse last added entry, if it ispresent.Relying on insn_idx comparison has the same ambiguity problem as the onethat was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: caif: Fix use-after-free in cfusbl_device_notify()syzbot reported use-after-free in cfusbl_device_notify() [1]. Thiscauses a stack trace like below:BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 When unregistering a net device, unregister_netdevice_many_notify()sets the device's reg_state to NETREG_UNREGISTERING, calls notifierswith NETDEV_UNREGISTER, and adds the device to the todo list.Later on, devices in the todo list are processed by netdev_run_todo().netdev_run_todo() waits devices' reference count become 1 whilerebdoadcasting NETDEV_UNREGISTER notification.When cfusbl_device_notify() is called with NETDEV_UNREGISTER multipletimes, the parent device might be freed. This could cause UAF.Processing NETDEV_UNREGISTER multiple times also causes inbalance ofreference count for the module.This patch fixes the issue by accepting only first NETDEV_UNREGISTERnotification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix race on port outputassume the following setup on a single machine:1. An openvswitch instance with one bridge and default flows2. two network namespaces "server" and "client"3. two ovs interfaces "server" and "client" on the bridge4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues5. move the ends of the veth pairs to the respective network namespaces6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)7. start some http server on the server network namespace8. test if a client in the client namespace can reach the http serverwhen following the actions below the host has a chance of getting a cpustuck in a infinite loop:1. send a large amount of parallel requests to the http server (around 3000 curls should work)2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)there is a low chance that this will cause the below kernel cpu stuckmessage. If this does not happen just retry.Below there is also the output of bpftrace for the functions mentionedin the output.The series of events happening here is:1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net`3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs)5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 08. port deletion continues (but details are not relevant for this issue)9. at some future point the background task deletes the vportIf after 7. but before 9. a packet is send to the ovs vport (which isnot deleted at this point in time) which forwards it to the`dev_queue_xmit` flow even though the device is unregistering.In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there isa while loop (if the packet has a rx_queue recorded) that is infinite if`dev->real_num_tx_queues` is zero.To prevent this from happening we update `do_output` to handle deviceswithout carrier the same as if the device is not found (which wouldbe the code path after 9. is done).Additionally we now produce a warning in `skb_tx_hash` if we will hitthe infinite loop.bpftrace (first word is function name):__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2dp_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: domains: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: bdisp: Add missing check for create_workqueueAdd the check for the return value of the create_workqueuein order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix kernel crash due to null io->bioWe should return when io->bio is null before doing anything. Otherwise, panic.BUG: kernel NULL pointer dereference, address: 0000000000000010RIP: 0010:__submit_merged_write_cond+0x164/0x240 [f2fs]Call Trace: f2fs_submit_merged_write+0x1d/0x30 [f2fs] commit_checkpoint+0x110/0x1e0 [f2fs] f2fs_write_checkpoint+0x9f7/0xf00 [f2fs] ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] __checkpoint_and_complete_reqs+0x84/0x190 [f2fs] ? preempt_count_add+0x82/0xc0 ? __pfx_issue_checkpoint_thread+0x10/0x10 [f2fs] issue_checkpoint_thread+0x4c/0xf0 [f2fs] ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xff/0x130 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:recordmcount: Fix memory leaks in the uwrite functionCommon realloc mistake: 'file_append' nulled but not freed upon failure
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/fail_function: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix device management cmd timeout flowIn the UFS error handling flow, the host will send a device management cmd(NOP OUT) to the device for link recovery. If this cmd times out andclearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing andreturn. hba->dev_cmd.complete struct is not set to NULL.When this happens, if cmd has been completed by device, then we will callcomplete() in __ufshcd_transfer_req_compl(). Because the complete struct isallocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/blktrace: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: ULPI: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: EM: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect rcu_print_task_exp_stall() ->exp_tasks accessFor kernels built with CONFIG_PREEMPT_RCU=y, the following scenario canresult in a NULL-pointer dereference: CPU1 CPU2rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) .... raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer)The problem is that CPU2 accesses the rcu_node structure's->exp_tasksfield without holding the rcu_node structure's ->lock and CPU2 didnot observe CPU1's change to rcu_node structure's ->exp_tasks in time.Therefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL,then CPU2 might dereference that NULL pointer.This commit therefore holds the rcu_node structure's ->lock whileaccessing that structure's->exp_tasks field.[ paulmck: Apply Frederic Weisbecker feedback. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: remove a BUG_ON in ext4_mb_release_group_pa()If a malicious fuzzer overwrites the ext4 superblock while it ismounted such that the s_first_data_block is set to a very largenumber, the calculation of the block group can underflow, and triggera BUG_ON check. Change this to be an ext4_warning so that we don'tcrash the kernel.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix memory leak in rtw_usb_probe()drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811Fix this by modifying return to a goto statement.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup()devm_kzalloc() may fail, clk_data->name might be NULL and willcause a NULL pointer dereference later.[ rjw: Subject and changelog edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: raspberrypi-ts - fix refcount leak in rpi_ts_proberpi_firmware_get() take reference, we need to release it in error pathsas well. Use devm_rpi_firmware_get() helper to handling the resources.Also remove the existing rpi_firmware_put().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: mtk_drm_crtc: Add checks for devm_kcallocAs the devm_kcalloc may return NULL, the return value needs to be checkedto avoid NULL poineter dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phyFor some reason, the driver adding support for Exynos5420 MIPI phyback in 2016 wasn't used on Exynos5420, which caused a kernel panic.Add the proper compatible for it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix sdma v4 sw fini errorFix sdma v4 sw fini error for sdma 4.2.2 tosolve the following general protection fault[ +0.108196] general protection fault, probably for non-canonicaladdress 0xd5e5a4ae79d24a32: 0000 [#1] PREEMPT SMP PTI[ +0.000018] RIP: 0010:free_fw_priv+0xd/0x70[ +0.000022] Call Trace:[ +0.000012] [ +0.000011] release_firmware+0x55/0x80[ +0.000021] amdgpu_ucode_release+0x11/0x20 [amdgpu][ +0.000415] amdgpu_sdma_destroy_inst_ctx+0x4f/0x90 [amdgpu][ +0.000360] sdma_v4_0_sw_fini+0xce/0x110 [amdgpu]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Add null pointer check in gserial_resumeConsider a case where gserial_disconnect has already clearedgser->ioport. And if a wakeup interrupt triggers afterwards,gserial_resume gets called, which will lead to accessing ofgser->ioport and thus causing null pointer dereference.Adda null pointer check to prevent this.Added a static spinlock to prevent gser->ioport from becomingnull after the newly added check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: fix vram leak on bind errorsMake sure to release the VRAM buffer also in a case a subcomponent failsto bind.Patchwork: https://patchwork.freedesktop.org/patch/525094/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix defrag path triggering jbd2 ASSERTcode path:ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERTcrash stacks:PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]AnalysisThis bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: callocfs2_journal_access_di() before ocfs2_journal_dirty() inocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() iscalled by ocfs2_split_extent() during defragmenting.How to fixFor ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller onlyneeds to call journal start/stop pair. The fix method is to removejournal access/dirty from __ocfs2_move_extent().The discussion for this patch:https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_rbtree: fix null deref on element insertionThere is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem():general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30Furthermore, there is a possible use-after-free while iterating,'node' can be free'd so we need to cache the next value to use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: qup: Don't skip cleanup in remove's error pathReturning early in a platform driver's remove callback is wrong. In thiscase the dma resources are not released in the error path. this is neverretried later and so this is a permanent leak. To fix this, only skiphardware disabling if waking the device fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Make intel_get_crtc_new_encoder() less oopsyThe point of the WARN was to print something, not oopsstraight up. Currently that is precisely what happensif we can't find the connector for the crtc in the atomicstate. Get the dev pointer from the atomic state insteadof the potentially NULL encoder to avoid that.(cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: Always check queue mode setting from configfsMake sure to check device queue mode in the null_validate_conf() andreturn error for NULL_Q_RQ as we don't allow legacy I/O path, withoutthis patch we get OOPs when queue mode is set to 1 from configfs,following are repro steps :-modprobe null_blk nr_devices=0mkdir config/nullb/nullb0echo 1 > config/nullb/nullb0/memory_backedecho 4096 > config/nullb/nullb0/blocksizeecho 20480 > config/nullb/nullb0/sizeecho 1 > config/nullb/nullb0/queue_modeecho 1 > config/nullb/nullb0/powerEntering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)due to oops @ 0xffffffffc041c329CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48aDR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400Call Trace: nullb_device_power_store+0xd1/0x120 [null_blk] configfs_write_iter+0xb4/0x120 vfs_write+0x2ba/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7fd4460c57a7Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->typeequals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbotscenario. This triggers the uninit variable access bug.Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX inqrtr_endpoint_post() to fix the bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix deadlock in tc route query codeCited commit causes ABBA deadlock[0] when peer flows are created whileholding the devcom rw semaphore. Due to peer flows offload implementationthe lock is taken much higher up the call chain and there is no obvious wayto easily fix the deadlock. Instead, since tc route query code needs thepeer eswitch structure only to perform a lookup in xarray and doesn'tperform any sleeping operations with it, refactor the code for locklessexecution in following ways:- RCUify the devcom 'data' pointer. When resetting the pointersynchronously wait for RCU grace period before returning. This is finesince devcom is currently only used for synchronization ofpairing/unpairing of eswitches which is rare and already expensive as-is.- Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag hasalready been used in some unlocked contexts without properannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn'tan issue since all relevant code paths checked it again after obtaining thedevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as"best effort" check to return NULL when devcom is being unpaired. Note thatwhile RCU read lock doesn't prevent the unpaired flag from being changedconcurrently it still guarantees that reader can continue to use 'data'.- Refactor mlx5e_tc_query_route_vport() function to use newmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.[0]:[ 164.599612] ======================================================[ 164.600142] WARNING: possible circular locking dependency detected[ 164.600667] 6.3.0-rc3+ #1 Not tainted[ 164.601021] ------------------------------------------------------[ 164.601557] handler1/3456 is trying to acquire lock:[ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core][ 164.603078] but task is already holding lock:[ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core][ 164.604459] which lock already depends on the new lock.[ 164.605190] the existing dependency chain (in reverse order) is:[ 164.605848] -> #1 (&comp->sem){++++}-{3:3}:[ 164.606380] down_read+0x39/0x50[ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core][ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core][ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core][ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core][ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core][ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core][ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core][ 164.610741] tc_setup_cb_add+0xd4/0x200[ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower][ 164.611661] fl_change+0xc95/0x18a0 [cls_flower][ 164.612116] tc_new_tfilter+0x3fc/0xd20[ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0[ 164.612936] netlink_rcv_skb+0x54/0x100[ 164.613339] netlink_unicast+0x190/0x250[ 164.613746] netlink_sendmsg+0x245/0x4a0[ 164.614150] sock_sendmsg+0x38/0x60[ 164.614522] ____sys_sendmsg+0x1d0/0x1e0[ 164.614934] ___sys_sendmsg+0x80/0xc0[ 164.615320] __sys_sendmsg+0x51/0x90[ 164.615701] do_syscall_64+0x3d/0x90[ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}:[ 164.617210] __lock_acquire+0x159e/0x26e0[ 164.617638] lock_acquire+0xc2/0x2a0[ 164.618018] __mutex_lock+0x92/0xcd0[ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core][ 164.618943] post_process_attr+0x153/0x2d0 [---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix resource leak in device_add()When calling kobject_add() failed in device_add(), it will callcleanup_glue_dir() to free resource. But in kobject_add(),dev->kobj.parent has been set to NULL. This will cause resource leak.The process is as follows:device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()The preceding problem may cause insmod mac80211_hwsim.ko to failed.sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'Call Trace:dump_stack_lvl+0x8e/0xd1sysfs_warn_dup.cold+0x1c/0x29sysfs_create_dir_ns+0x224/0x280kobject_add_internal+0x2aa/0x880kobject_add+0x135/0x1a0get_device_parent+0x3d7/0x590device_add+0x2aa/0x1cb0device_create_groups_vargs+0x1eb/0x260device_create+0xdc/0x110mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]do_one_initcall+0x10f/0x630do_init_module+0x19f/0x5e0load_module+0x64b7/0x6eb0__do_sys_finit_module+0x140/0x200do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try toregister things with the same name in the same directory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Range check CHDBOFF and ERDBOFFIf the value read from the CHDBOFF and ERDBOFF registers is outside therange of the MHI register space then an invalid address might be computedwhich later causes a kernel panic. Range check the read value to preventa crash due to bad data from the device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ymfpci: Fix BUG_ON in probe functionThe snd_dma_buffer.bytes field now contains the aligned size, which thissnd_BUG_ON() did not account for, resulting in the following:[ 9.625915] ------------[ cut here ]------------[ 9.633440] WARNING: CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci][ 9.648926] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_core xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy[ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da[ 9.722200] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014[ 9.732204] Workqueue: events work_for_cpu_fn[ 9.736580] RIP: 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci][ 9.742594] Code: 8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41 bd fb ff ff ff eb db 41 bd f4 ff ff ff eb[ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287[ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8[ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020[ 9.780876] RBP: ffff8fa300b5d0d0 R08: ffff8fa3073a8e50 R09: 00000000df06bf00[ 9.788018] R10: ffff8fa2df06bf00 R11: 00000000df068200 R12: ffff8fa3073a8918[ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200[ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000[ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4: 00000000000406f0[ 9.823301] Call Trace:[ 9.825747] [ 9.827889] snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615][ 9.837030] ? finish_task_switch.isra.0+0x90/0x2d0[ 9.841918] local_pci_probe+0x45/0x80[ 9.845680] work_for_cpu_fn+0x1a/0x30[ 9.849431] process_one_work+0x1c7/0x380[ 9.853464] worker_thread+0x1af/0x390[ 9.857225] ? rescuer_thread+0x3b0/0x3b0[ 9.861254] kthread+0xde/0x110[ 9.864414] ? kthread_complete_and_exit+0x20/0x20[ 9.869210] ret_from_fork+0x22/0x30[ 9.872792] [ 9.874985] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix soft lockup in status_resyncstatus_resync() will calculate 'curr_resync - recovery_active' to showuser a progress bar like following:[============>........] resync = 61.4%'curr_resync' and 'recovery_active' is updated in md_do_sync(), andstatus_resync() can read them concurrently, hence it's possible that'curr_resync - recovery_active' can overflow to a huge number. In thiscase status_resync() will be stuck in the loop to print a large amountof '=', which will end up soft lockup.Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,this way resync in progress will be reported to user.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gvt: fix vgpu debugfs clean in removeCheck carefully on root debugfs available when destroying vgpu,e.g in remove case drm minor's debugfs root might already be destroyed,which led to kernel oops like below.Console: switching to colour dummy device 80x25i915 0000:00:02.0: MDEV: Unregisteringintel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14BUG: kernel NULL pointer dereference, address: 0000000000000150PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMPCPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022RIP: 0010:__lock_acquire+0x5e2/0x1f90Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0RSP: 0018:ffff9f770274f948 EFLAGS: 00010046RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: lock_acquire+0xbf/0x2b0 ? simple_recursive_removal+0xa5/0x2b0 ? lock_release+0x13d/0x2d0 down_write+0x2a/0xd0 ? simple_recursive_removal+0xa5/0x2b0 simple_recursive_removal+0xa5/0x2b0 ? start_creating.part.0+0x110/0x110 ? _raw_spin_unlock+0x29/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt] intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt] intel_vgpu_release_dev+0xe/0x20 [kvmgt] device_release+0x30/0x80 kobject_put+0x79/0x1b0 device_release_driver_internal+0x1b8/0x230 bus_remove_device+0xec/0x160 device_del+0x189/0x400 ? up_write+0x9c/0x1b0 ? mdev_device_remove_common+0x60/0x60 [mdev] mdev_device_remove_common+0x22/0x60 [mdev] mdev_device_remove_cb+0x17/0x20 [mdev] device_for_each_child+0x56/0x80 mdev_unregister_parent+0x5a/0x81 [mdev] intel_gvt_clean_device+0x2d/0xe0 [kvmgt] intel_gvt_driver_remove+0x2e/0xb0 [i915] i915_driver_remove+0xac/0x100 [i915] i915_pci_remove+0x1a/0x30 [i915] pci_device_remove+0x31/0xa0 device_release_driver_internal+0x1b8/0x230 unbind_store+0xd8/0x100 kernfs_fop_write_iter+0x156/0x210 vfs_write+0x236/0x4a0 ksys_write+0x61/0xd0 do_syscall_64+0x55/0x80 ? find_held_lock+0x2b/0x80 ? lock_release+0x13d/0x2d0 ? up_read+0x17/0x20 ? lock_is_held_type+0xe3/0x140 ? asm_exc_page_fault+0x22/0x30 ? lockdep_hardirqs_on+0x7d/0x100 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7fc9b2c9e0c4Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4RDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000dR13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00 Modules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.listWhen freeing slots in function slot_complete_v3_hw(), it is possible thatsas_dev.list is being traversed elsewhere, and it may trigger a NULLpointer exception, such as follows:==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task()==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe()[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32[ 7165.434926] sas: trying to find task 0x00000000769b5ba5[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored[ 7165.434976] Mem abort info:[ 7165.434982] ESR = 0x96000004[ 7165.434991] Exception class = DABT (current EL), IL = 32 bits[ 7165.434992] SET = 0, FnV = 0[ 7165.434993] EA = 0, S1PTW = 0[ 7165.434994] Data abort info:[ 7165.434994] ISV = 0, ISS = 0x00000004[ 7165.434995] CM = 0, WnR = 0[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2[ 7165.434998] [0000000000000000] pgd=0000000000000000[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw][ 7165.485247] sp : ffff00001d623bc0[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e[ 7165.567872] Call trace:[ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main][ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas][ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas][ 7165.592082] scsi_error_handler+0xb4/0x488[ 7165.596163] kthread+0x134/0x138[ 7165.599380] ret_from_fork+0x10/0x18[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)[ 7165.609004] kernel fault(0x1) notification starting on CPU 75[ 7165.700728] ---[ end trace fc042cbbea224efc ]---[ 7165.705326] Kernel panic - not syncing: Fatal exceptionTo fix the issue, grab sas_dev lock when traversing the members ofsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoidconcurrency of adding and deleting member. When ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov772x: Fix memleak in ov772x_probe()A memory leak was reported when testing ov772x with bpf mock device:AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110The reason is that if priv->hdl.error is set, ov772x_probe() jumps to theerror_mutex_destroy without doing v4l2_ctrl_handler_free(), and allresources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()are leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: radio-shark: Add endpoint checksThe syzbot fuzzer was able to provoke a WARNING from the radio-shark2driver:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edacRBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387 shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88...The problem was caused by the fact that the driver does not checkwhether the endpoints it uses are actually present and have theappropriate types. This can be fixed by adding a simple check ofthese endpoints (and similarly for the radio-shark driver).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible desc_ptr out-of-bounds accessesSanitize possible desc_ptr out-of-bounds accesses inses_enclosure_data_process().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt7601u: fix an integer underflowFix an integer underflow that leads to a null pointer dereference in'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packetcould be manipulated, which could trigger an integer underflow of'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequentlycauses the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to bebypassed, eventually leading to a dereference of the pointer 'p', whichis a null pointer.Ensure that 'dma_len' is greater than 'min_seg_len'.Found by a modified version of syzkaller.KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+#139Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014RIP: 0010:skb_add_rx_frag+0x143/0x370Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 4489 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 0200 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008FS: 0000000000000000(0000) GS:ffff88811a800000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: mt7601u_rx_tasklet+0xc73/0x1270 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510 ? tasklet_action_common.isra.0+0x79/0x2f0 tasklet_action_common.isra.0+0x206/0x2f0 __do_softirq+0x1b5/0x880 ? tasklet_unlock+0x30/0x30 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x34f/0x7d0 ? smpboot_register_percpu_thread+0x370/0x370 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30Modules linked in: 88XXau(O) 88x2bu(O)---[ end trace 57f34f93b4da0f9b ]---RIP: 0010:skb_add_rx_frag+0x143/0x370Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 4489 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 0200 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008FS: 0000000000000000(0000) GS:ffff88811a800000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGALOPDESC() simply indexes into nfsd4_ops[] by the op's operationnumber, without range checking that value. It assumes callers arecareful to avoid calling it with an out-of-bounds opnum value.nfsd4_decode_compound() is not so careful, and can invoke OPDESC()with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the endof nfsd4_ops[].
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Zero padding when dumping algos and encapWhen copying data to user-space we should ensure that only validdata is copied over. Padding in structures may be filled withrandom (possibly sensitve) data and should never be given directlyto user-space.This patch fixes the copying of xfrm algorithms and the encaptemplate in xfrm_user so that padding is zeroed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free read in ext4_find_extent for bigalloc + inlineSyzbot found the following issue:loop0: detected capacity change from 0 to 2048EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.==================================================================BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931Read of size 4 at addr ffff888073644750 by task syz-executor420/5067CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809 ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline] ext4_da_map_blocks fs/ext4/inode.c:1806 [inline] ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870 ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098 ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285 ext4_file_write_iter+0x1d0/0x18f0 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f4b7a9737b9RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Above issue is happens when enable bigalloc and inline data feature. Ascommit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped forbigalloc + inline. But it only resolved issue when has inline data, ifinline data has been converted to extent(ext4_da_convert_inline_data_to_extent)before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. Howeveri_data is still store inline data in this scene. Then will trigger UAFwhen find extent.To resolve above issue, there is need to add judge "ext4_has_inline_data(inode)"in ext4_clu_mapped().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()There is a memory leak reported by kmemleak: unreferenced object 0xffffc900003f0000 (size 12288): comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx] [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx] [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0The root cause is traced to an error-handling path in qla2x00_probe_one()when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" isused to record the port information and it is allocated inqla2x00_create_host(). However, it is not released in the error handlingpath "probe_failed".Fix this by freeing the memory of "scan.l" when an error occurs in theadapter initialization process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: max9286: Fix memleak in max9286_v4l2_register()There is a kmemleak when testing the media/i2c/max9286.c with bpf mockdevice:kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak)unreferenced object 0xffff88810defc400 (size 256): comm "python3", pid 278, jiffies 4294737563 (age 31.978s) hex dump (first 32 bytes): 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (........."..... 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................ backtrace: [<00000000191de6a7>] __kmalloc_node+0x44/0x1b0 [<000000002f4912b7>] kvmalloc_node+0x34/0x180 [<0000000057dc4cae>] v4l2_ctrl_new+0x325/0x10f0 [videodev] [<0000000026030272>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000f0d9ea2f>] max9286_probe+0x76e/0xbff [max9286] [<00000000ea8f6455>] i2c_device_probe+0x28d/0x680 [<0000000087529af3>] really_probe+0x17c/0x3f0 [<00000000b08be526>] __driver_probe_device+0xe3/0x170 [<000000004382edea>] driver_probe_device+0x49/0x120 [<000000007bde528a>] __device_attach_driver+0xf7/0x150 [<000000009f9c6ab4>] bus_for_each_drv+0x114/0x180 [<00000000c8aaf588>] __device_attach+0x1e5/0x2d0 [<0000000041cc06b9>] bus_probe_device+0x126/0x140 [<000000002309860d>] device_add+0x810/0x1130 [<000000002827bf98>] i2c_new_client_device+0x359/0x4f0 [<00000000593bdc85>] of_i2c_register_device+0xf1/0x110max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won't free thecreated v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, whichcauses the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Handle race between rb_move_tail and rb_check_pagesIt seems a data race between ring_buffer writing and integrity check.That is, RB_FLAG of head_page is been updating, while at same timeRB_FLAG was cleared when doing integrity check rb_check_pages(): rb_check_pages() rb_handle_head_page(): -------- -------- rb_head_page_deactivate() rb_head_page_set_normal() rb_head_page_activate()We do intergrity test of the list to check if the list is corrupted andit is still worth doing it. So, let's refactor rb_check_pages() such thatwe no longer clear and set flag during the list sanity checking.[1] and [2] are the test to reproduce and the crash report respectively.1:``` read_trace.sh while true; do # the "trace" file is closed after read head -1 /sys/kernel/tracing/trace > /dev/null done`````` repro.sh sysctl -w kernel.panic_on_warn=1 # function tracer will writing enough data into ring_buffer echo function > /sys/kernel/tracing/current_tracer ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh &```2:------------[ cut here ]------------WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653rb_move_tail+0x450/0x470Modules linked in:CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G W 6.2.0-rc6+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:rb_move_tail+0x450/0x470Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 2483 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 <0f> 0b 83f8 02 0f 84 ce fb ff ff e9 dbRSP: 0018:ffffb5564089bd00 EFLAGS: 00000203RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0Call Trace: ring_buffer_lock_reserve+0x136/0x360 ? __do_softirq+0x287/0x2df ? __pfx_rcu_softirq_qs+0x10/0x10 trace_function+0x21/0x110 ? __pfx_rcu_softirq_qs+0x10/0x10 ? __do_softirq+0x287/0x2df function_trace_call+0xf6/0x120 0xffffffffc038f097 ? rcu_softirq_qs+0x5/0x140 rcu_softirq_qs+0x5/0x140 __do_softirq+0x287/0x2df run_ksoftirqd+0x2a/0x30 smpboot_thread_fn+0x188/0x220 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0xe7/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ---[ end trace 0000000000000000 ]---[ crash report and test reproducer credit goes to Zheng Yejian]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:um: vector: Fix memory leak in vector_configIf the return value of the uml_parse_vector_ifspec function is NULL,we should call kfree(params) to prevent memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setupvariable *nplanes is provided by user via system call argument. Thepossible value of q_data->fmt->num_planes is 1-3, while the valueof *nplanes can be 1-8. The array access by index i can cause arrayout-of-bounds.Fix this bug by checking *nplanes against the array size.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_syncUse-after-free can occur in hci_disconnect_all_sync if a connection isdeleted by concurrent processing of a controller event.To prevent this the code now tries to iterate over the list backwardsto ensure the links are cleanup before its parents, also it no longerrelies on a cursor, instead it always uses the last element sincehci_abort_conn_sync is guaranteed to call hci_conn_del.UAF crash log:==================================================================BUG: KASAN: slab-use-after-free in hci_set_powered_sync(net/bluetooth/hci_sync.c:5424) [bluetooth]Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W6.5.0-rc1+ #10Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.16.2-1.fc38 04/01/2014Workqueue: hci0 hci_cmd_sync_work [bluetooth]Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xdd/0x160 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] kasan_report+0xa6/0xe0 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_cmd_sync_work+0x137/0x220 [bluetooth] process_one_work+0x526/0x9d0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x1a/0x90 worker_thread+0x92/0x630 ? __pfx_worker_thread+0x10/0x10 kthread+0x196/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 Allocated by task 1782: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 hci_conn_add+0xa5/0xa80 [bluetooth] hci_bind_cis+0x881/0x9b0 [bluetooth] iso_connect_cis+0x121/0x520 [bluetooth] iso_sock_connect+0x3f6/0x790 [bluetooth] __sys_connect+0x109/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 695: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10a/0x180 __kmem_cache_free+0x14d/0x2e0 device_release+0x5d/0xf0 kobject_put+0xdf/0x270 hci_disconn_complete_evt+0x274/0x3a0 [bluetooth] hci_event_packet+0x579/0x7e0 [bluetooth] hci_rx_work+0x287/0xaa0 [bluetooth] process_one_work+0x526/0x9d0 worker_thread+0x92/0x630 kthread+0x196/0x1e0 ret_from_fork+0x2c/0x50==================================================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: don't assume adequate headroom for SDIO headersmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() andmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume thatadequate headroom will be available in the passed skb. This assumptiontypically is satisfied when the skb was allocated in the net core fortransmission via the mt7921 netdev (although even that is only anoptimization and is not strictly guaranteed), but the assumption issometimes not satisfied when the skb originated in the receive path ofanother netdev and was passed through to the mt7921, such as by thebridge layer. Blindly prepending bytes to an skb is always wrong.This commit introduces a call to skb_cow_head() before the call tomt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() toensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can bepushed onto the skb.Without this fix, I can trivially cause kernel panics by bridging anMT7921AU-based USB 802.11ax interface with an Ethernet interface on anIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernetadapter and also on an ARM-based Raspberry Pi 1 using its onboardSMSC9512 USB Ethernet adapter. Note that the panics do not occur inevery system configuration, as they occur only if the receiving netdevleaves less headroom in its received skbs than the mt7921 needs for itsSDIO headers.Here is an example stack trace of this panic on Raspberry Pi OS Lite2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34After this fix, bridging the mt7921 interface works fine on both of mypreviously problematic systems.[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Improve page fault error reportingIf IOMMU domain for device group is not setup properly then we may hitIOMMU page fault. Current page fault handler assumes that domain isalways setup and it will hit NULL pointer derefence (see below sample log).Lets check whether domain is setup or not and log appropriate message.Sample log:---------- amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6 BUG: kernel NULL pointer dereference, address: 0000000000000058 #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: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89 Hardware name: xxx RIP: 0010:report_iommu_fault+0x11/0x90 [...] Call Trace: amd_iommu_int_thread+0x60c/0x760 ? __pfx_irq_thread_fn+0x10/0x10 irq_thread_fn+0x1f/0x60 irq_thread+0xea/0x1a0 ? preempt_count_add+0x6a/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xe9/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 [joro: Edit commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Fix uninitialized number of lanesIt is not possible to set the number of lanes when setting link modesusing the legacy IOCTL ethtool interface. Since 'structethtool_link_ksettings' is not initialized in this path, drivers receivean uninitialized number of lanes in 'structethtool_link_ksettings::lanes'.When this information is later queried from drivers, it results in theethtool code making decisions based on uninitialized memory, leading tothe following KMSAN splat [1]. In practice, this most likely onlyhappens with the tun driver that simply returns whatever it got in theset operation.As far as I can tell, this uninitialized memory is not leaked to userspace thanks to the 'ethtool_ops->cap_link_lanes_supported' check inlinkmodes_prepare_data().Fix by initializing the structure in the IOCTL path. Did not find anymore call sites that pass an uninitialized structure when calling'ethtool_ops::set_link_ksettings()'.[1]BUG: KMSAN: uninit-value in ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]BUG: KMSAN: uninit-value in ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline] ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c:3544 __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441 ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c:3553 ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609 __dev_ethtool net/ethtool/ioctl.c:3024 [inline] dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078 dev_ioctl+0xb07/0x1270 net/core/dev_ioctl.c:524 sock_do_ioctl+0x295/0x540 net/socket.c:1213 sock_i---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: api - Use work queue in crypto_destroy_instanceThe function crypto_drop_spawn expects to be called in processcontext. However, when an instance is unregistered while it stillhas active users, the last user may cause the instance to be freedin atomic context.Fix this by delaying the freeing to a work queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()Smatch detected this potential error pointer dereferenceclk_wzrd_register_divider(). If devm_clk_hw_register() fails thenit sets "hw" to an error pointer and then dereferences it on thenext line. Return the error directly instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: release crypto keyslot before reporting I/O completeOnce all I/O using a blk_crypto_key has completed, filesystems can callblk_crypto_evict_key(). However, the block layer currently doesn't callblk_crypto_put_keyslot() until the request is being freed, which happensafter upper layers have been told (via bio_endio()) the I/O hascompleted. This causes a race condition where blk_crypto_evict_key()can see 'slot_refs != 0' without there being an actual bug.This makes __blk_crypto_evict_key() hit the'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return withoutdoing anything, eventually causing a use-after-free inblk_crypto_reprogram_all_keys(). (This is a very rare bug and has onlybeen seen when per-file keys are being used with fscrypt.)There are two options to fix this: either release the keyslot beforebio_endio() is called on the request's last bio, or make__blk_crypto_evict_key() ignore slot_refs. Let's go with the firstsolution, since it preserves the ability to report bugs (viaWARN_ON_ONCE) where a key is evicted while still in-use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Prevent RT livelock in itimer_delete()itimer_delete() has a retry loop when the timer is concurrently expired. Onnon-RT kernels this just spin-waits until the timer callback has completed,except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORKenabled.In that case and on RT kernels the existing task could live lock whenpreempting the task which does the timer delivery.Replace spin_unlock() with an invocation of timer_wait_running() to handleit the same way as the other retry loops in the posix timer code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Ignore frags from uninitialized peer in dp.When max virtual ap interfaces are configured in all the bands withACS and hostapd restart is done every 60s, a crash is observed atrandom times.In this certain scenario, a fragmented packet is received forself peer, for which rx_tid and rx_frags are not initialized indatapath. While handling this fragment, crash is observed as therx_frag list is uninitialised and when we walk inath11k_dp_rx_h_sort_frags, skb null leads to exception.To address this, before processing received fragments we checkdp_setup_done flag is set to ensure that peer has completed itsdp peer setup for fragment queue, else ignore processing thefragments.Call trace: ath11k_dp_process_rx_err+0x550/0x1084 [ath11k] ath11k_dp_service_srng+0x70/0x370 [ath11k] 0xffffffc009693a04 __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0/0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 start_kernel+0x480/0x4b8 Code: f9400281 f94066a2 91405021 b94a0023 (f9406401)Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block/rq_qos: protect rq_qos apis with a new lockcommit 50e34d78815e ("block: disable the elevator int del_gendisk")move rq_qos_exit() from disk_release() to del_gendisk(), this willintroduce some problems:1) If rq_qos_add() is triggered by enabling iocost/iolatency through cgroupfs, then it can concurrent with del_gendisk(), it's not safe to write 'q->rq_qos' concurrently.2) Activate cgroup policy that is relied on rq_qos will call rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is called in the middle, null-ptr-dereference will be triggered in blkcg_activate_policy().3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the disk, then if rq_qos_exit() from del_gendisk() is done before rq_qos_add(), then memory will be leaked.This patch add a new disk level mutex 'rq_qos_mutex':1) The lock will protect rq_qos_exit() directly.2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be called from disk initialization for now because wbt can't be destructed until rq_qos_exit(), so it's safe not to protect wbt for now. Hoever, in case that rq_qos dynamically destruction is supported in the furture, this patch also protect rq_qos_add() from wbt_init() directly, this is enough because blk-sysfs already synchronize writers with disk removal.3) For iocost and iolatency, in order to synchronize disk removal and cgroup configuration, the lock is held after blkdev_get_no_open() from blkg_conf_open_bdev(), and is released in blkg_conf_exit(). In order to fix the above memory leak, disk_live() is checked after holding the new lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate lockless accesses to nlk->max_recvmsg_lensyzbot reported a data-race in data-race in netlink_recvmsg() [1]Indeed, netlink_recvmsg() can be run concurrently,and netlink_dump() also needs protection.[1]BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsgread to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]__sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194__do_sys_recvfrom net/socket.c:2212 [inline]__se_sys_recvfrom net/socket.c:2208 [inline]__x64_sys_recvfrom+0x78/0x90 net/socket.c:2208do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdwrite to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]____sys_recvmsg+0x156/0x310 net/socket.c:2720___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x0000000000000000 -> 0x0000000000001000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it byupdating kcm_tx_msg(head)->last_skb if partial data is copied so that thefollowing sendmsg() will resume from the skb.However, we cannot know how many bytes were copied when we get the error.Thus, we could mess up the MSG_MORE queue.When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as wedo so for UDP by udp_flush_pending_frames().Even without this change, when the error occurred, the following sendmsg()resumed from a wrong skb and the queue was messed up. However, we haveyet to get such a report, and only syzkaller stumbled on it. So, thiscan be changed safely.Note this does not change SOCK_SEQPACKET behaviour.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: read sk->sk_family once in sk_mc_loop()syzbot is playing with IPV6_ADDRFORM quite a lot these days,and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()We have many more similar issues to fix.WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260Modules linked in:CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023Workqueue: events_power_efficient gc_workerRIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48RSP: 0018:ffffc90000388530 EFLAGS: 00010246RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83[] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline][] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211[] NF_HOOK_COND include/linux/netfilter.h:298 [inline][] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232[] dst_output include/net/dst.h:444 [inline][] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342[] qdisc_restart net/sched/sch_generic.c:407 [inline][] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415[] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125[] net_tx_action+0x7ac/0x940 net/core/dev.c:5247[] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599[] invoke_softirq kernel/softirq.c:430 [inline][] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683[] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix skb refcnt race after locking changesThere is a race where skb's from the sk_psock_backlog can be referencedafter userspace side has already skb_consumed() the sk_buff and its refcntdropped to zer0 causing use after free.The flow is the following: while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This iswhat the application reads when recvmsg() is called. An application canread this anytime after the msg is placed on the queue. The recvmsg hookwill also read msg->skb and then after user space reads the msg will callconsume_skb(skb) on it effectively free'ing it.But, the race is in above where backlog queue still has a reference tothe skb and calls skb_dequeue(). If the skb_dequeue happens after theuser reads and free's the skb we have a use after free.The !ingress case does not suffer from this problem because it usessendmsg_*(sk, msg) which does not pass the sk_buff further down thestack.The following splat was observed with 'test_progs -t sockmap_listen': [ 1022.710250][ T2556] general protection fault, ... [...] [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80 [ 1022.713653][ T2556] Code: ... [...] [ 1022.720699][ T2556] Call Trace: [ 1022.720984][ T2556] [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0 [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30 [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80 [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300 [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0 [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0 [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10 [ 1022.724386][ T2556] kthread+0xfd/0x130 [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50 [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30 [ 1022.726201][ T2556] To fix we add an skb_get() before passing the skb to be enqueued in theengress queue. This bumps the skb->users refcnt so that consume_skb()and kfree_skb will not immediately free the sk_buff. With this we canbe sure the skb is still around when we do the dequeue. Then we justneed to decrement the refcnt or free the skb in the backlog case whichwe do by calling kfree_skb() on the ingress case as well as the sendmsgcase.Before locking change from fixes tag we had the sock locked so wecouldn't race with user and there was no issue here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on direct node in truncate_dnode()syzbot reports below bug:BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h:825 [inline] f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [inline] do_open fs/namei.c:3640 [inline] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_creat fs/open.c:1448 [inline] __se_sys_creat fs/open.c:1442 [inline] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root cause is, inodeA references inodeB via inodeB's ino, once inodeAis truncated, it calls truncate_dnode() to truncate data blocks in inodeB'snode page, it traverse mapping data from node->i.i_addr[0] tonode->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.This patch fixes to add sanity check on dnode page in truncate_dnode(),so that, it can help to avoid triggering such issue, and once it encounterssuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCEerror into superblock, later fsck can detect such issue and try repairing.Also, it removes f2fs_truncate_data_blocks() for cleanup due to thefunction has only one caller, and uses f2fs_truncate_data_blocks_range()instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dp: Drop aux devices together with DP controllerUsing devres to depopulate the aux bus made sure that upon a probedeferral the EDP panel device would be destroyed and recreated upon nextattempt.But the struct device which the devres is tied to is the DPUs(drm_dev->dev), which may be happen after the DP controller is torndown.Indications of this can be seen in the commonly seen EDID-hexdump fullof zeros in the log, or the occasional/rare KASAN fault where thepanel's attempt to read the EDID information causes a use after free onDP resources.It's tempting to move the devres to the DP controller's struct device,but the resources used by the device(s) on the aux bus are explicitlytorn down in the error path. The KASAN-reported use-after-free alsoremains, as the DP aux "module" explicitly frees its devres-allocatedmemory in this code path.As such, explicitly depopulate the aux bus in the error path, and in thecomponent unbind path, to avoid these issues.Patchwork: https://patchwork.freedesktop.org/patch/542163/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate accesses to nlk->cb_runningBoth netlink_recvmsg() and netlink_native_seq_show() readnlk->cb_running locklessly. Use READ_ONCE() there.Add corresponding WRITE_ONCE() to netlink_dump() and__netlink_dump_start()syzbot reported:BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsgwrite to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:__netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399netlink_dump_start include/linux/netlink.h:308 [inline]rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg net/socket.c:747 [inline]sock_write_iter+0x1aa/0x230 net/socket.c:1138call_write_iter include/linux/fs.h:1851 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x463/0x760 fs/read_write.c:584ksys_write+0xeb/0x1a0 fs/read_write.c:637__do_sys_write fs/read_write.c:649 [inline]__se_sys_write fs/read_write.c:646 [inline]__x64_sys_write+0x42/0x50 fs/read_write.c:646do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017____sys_recvmsg+0x2db/0x310 net/socket.c:2718___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x00 -> 0x01
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver removeWhen the tagging protocol in current use is "ocelot-8021q" and we unbindthe driver, we see this splat:$ echo '0000:00:00.2' > /sys/bus/pci/drivers/fsl_enetc/unbindmscc_felix 0000:00:00.5 swp0: left promiscuous modesja1105 spi2.0: Link is DownDSA: tree 1 torn downmscc_felix 0000:00:00.5 swp2: left promiscuous modesja1105 spi2.2: Link is DownDSA: tree 3 torn downfsl_enetc 0000:00:00.2 eno2: left promiscuous modemscc_felix 0000:00:00.5: Link is Down------------[ cut here ]------------RTNL: assertion failed at net/dsa/tag_8021q.c (409)WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0Modules linked in:CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771pc : dsa_tag_8021q_unregister+0x12c/0x1a0lr : dsa_tag_8021q_unregister+0x12c/0x1a0Call trace: dsa_tag_8021q_unregister+0x12c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50---[ end trace 0000000000000000 ]---------------[ cut here ]------------RTNL: assertion failed at net/8021q/vlan_core.c (376)WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771pc : vlan_vid_del+0x1b8/0x1f0lr : vlan_vid_del+0x1b8/0x1f0 dsa_tag_8021q_unregister+0x8c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50DSA: tree 0 torn downThis was somewhat not so easy to spot, because "ocelot-8021q" is not thedefault tagging protocol, and thus, not everyone who tests the unbindingpath may have switched to it beforehand. The defaultfelix_tag_npi_teardown() does not require rtnl_lock() to be held.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: Call of_changeset_init() earlyWhen of_overlay_fdt_apply() fails, the changeset may be partiallyapplied, and the caller is still expected to call of_overlay_remove() toclean up this partial state.However, of_overlay_apply() calls of_resolve_phandles() beforeinit_overlay_changeset(). Hence if the overlay fails to apply due to anunresolved symbol, the overlay_changeset.cset.entries list is stilluninitialized, and cleanup will crash with a NULL-pointer dereference inoverlay_removal_is_ok().Fix this by moving the call to of_changeset_init() frominit_overlay_changeset() to of_overlay_fdt_apply(), where all otherearly initialization is done.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: bpf_sk_storage: Fix invalid wait context lockdep report'./test_progs -t test_local_storage' reported a splat:[ 27.137569] =============================[ 27.138122] [ BUG: Invalid wait context ][ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O[ 27.139542] -----------------------------[ 27.140106] test_progs/1729 is trying to lock:[ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130[ 27.141834] other info that might help us debug this:[ 27.142437] context-{5:5}[ 27.142856] 2 locks held by test_progs/1729:[ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40[ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0[ 27.145855] stack backtrace:[ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247[ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 27.149127] Call Trace:[ 27.149490] [ 27.149867] dump_stack_lvl+0x130/0x1d0[ 27.152609] dump_stack+0x14/0x20[ 27.153131] __lock_acquire+0x1657/0x2220[ 27.153677] lock_acquire+0x1b8/0x510[ 27.157908] local_lock_acquire+0x29/0x130[ 27.159048] obj_cgroup_charge+0xf4/0x3c0[ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0[ 27.161931] __kmem_cache_alloc_node+0x51/0x210[ 27.163557] __kmalloc+0xaa/0x210[ 27.164593] bpf_map_kzalloc+0xbc/0x170[ 27.165147] bpf_selem_alloc+0x130/0x510[ 27.166295] bpf_local_storage_update+0x5aa/0x8e0[ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0[ 27.169199] bpf_map_update_value+0x415/0x4f0[ 27.169871] map_update_elem+0x413/0x550[ 27.170330] __sys_bpf+0x5e9/0x640[ 27.174065] __x64_sys_bpf+0x80/0x90[ 27.174568] do_syscall_64+0x48/0xa0[ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 27.175932] RIP: 0033:0x7effb40e41ad[ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d8[ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141[ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad[ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002[ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788[ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000[ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000[ 27.184958] It complains about acquiring a local_lock while holding a raw_spin_lock.It means it should not allocate memory while holding a raw_spin_locksince it is not safe for RT.raw_spin_lock is needed because bpf_local_storage supports tracingcontext. In particular for task local storage, it is easy toget a "current" task PTR_TO_BTF_ID in tracing bpf prog.However, task (and cgroup) local storage has already been moved tobpf mem allocator which can be used after raw_spin_lock.The splat is for the sk storage. For sk (and inode) storage,it has not been moved to bpf mem allocator. Using raw_spin_lock or not,kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.However, the local storage helper requires a verifier acceptedsk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean runninga bpf prog in a kzalloc unsafe context and also able to hold a verifieraccepted sk pointer) could happen.This patch avoids kzalloc after raw_spin_lock to silent the splat.There is an existing kzalloc before the raw_spin_lock. At that point,a kzalloc is very likely required because a lookup has just been donebefore. Thus, this patch always does the kzalloc before acq---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: do not hard code device address lenth in fdb dumpssyzbot reports that some netdev devices do not have a six bytesaddress [1]Replace ETH_ALEN by dev->addr_len.[1] (Case of a device where dev->addr_len = 4)BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169instrument_copy_to_user include/linux/instrumented.h:114 [inline]copyout+0xb8/0x100 lib/iov_iter.c:169_copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536copy_to_iter include/linux/uio.h:206 [inline]simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970sock_recvmsg_nosec net/socket.c:1019 [inline]sock_recvmsg net/socket.c:1040 [inline]____sys_recvmsg+0x283/0x7f0 net/socket.c:2722___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at:__nla_put lib/nlattr.c:1009 [inline]nla_put+0x1c6/0x230 lib/nlattr.c:1067nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019____sys_recvmsg+0x664/0x7f0 net/socket.c:2720___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at:slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716slab_alloc_node mm/slub.c:3451 [inline]__kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490kmalloc_trace+0x51/0x200 mm/slab_common.c:1057kmalloc include/linux/slab.h:559 [inline]__hw_addr_create net/core/dev_addr_lists.c:60 [inline]__hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118__dev_mc_add net/core/dev_addr_lists.c:867 [inline]dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708addrconf_type_change net/ipv6/addrconf.c:3731 [inline]addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699notifier_call_chain kernel/notifier.c:93 [inline]raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1935 [inline]call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906do_set_master net/core/rtnetlink.c:2626 [inline]rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]__rtnl_newlink net/core/rtnetlink.c:3660 [inline]rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0xf28/0x1230 net/netlink/af_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix warning when putting transaction with qgroups enabled after abortIf we have a transaction abort with qgroups enabled we get a warningtriggered when doing the final put on the transaction, like this: [552.6789] ------------[ cut here ]------------ [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs] [552.6817] Modules linked in: btrfs blake2b_generic xor (...) [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs] [552.6821] Code: bd a0 01 00 (...) [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286 [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000 [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010 [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20 [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70 [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028 [552.6821] FS: 0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000 [552.6821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0 [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [552.6822] Call Trace: [552.6822] [552.6822] ? __warn+0x80/0x130 [552.6822] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6824] ? report_bug+0x1f4/0x200 [552.6824] ? handle_bug+0x42/0x70 [552.6824] ? exc_invalid_op+0x14/0x70 [552.6824] ? asm_exc_invalid_op+0x16/0x20 [552.6824] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6826] btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs] [552.6828] ? _raw_spin_unlock_irqrestore+0x23/0x40 [552.6828] ? try_to_wake_up+0x94/0x5e0 [552.6828] ? __pfx_process_timeout+0x10/0x10 [552.6828] transaction_kthread+0x103/0x1d0 [btrfs] [552.6830] ? __pfx_transaction_kthread+0x10/0x10 [btrfs] [552.6832] kthread+0xee/0x120 [552.6832] ? __pfx_kthread+0x10/0x10 [552.6832] ret_from_fork+0x29/0x50 [552.6832] [552.6832] ---[ end trace 0000000000000000 ]---This corresponds to this line of code: void btrfs_put_transaction(struct btrfs_transaction *transaction) { (...) WARN_ON(!RB_EMPTY_ROOT( &transaction->delayed_refs.dirty_extent_root)); (...) }The warning happens because btrfs_qgroup_destroy_extent_records(), calledin the transaction abort path, we free all entries from the rbtree"dirty_extent_root" with rbtree_postorder_for_each_entry_safe(), but wedon't actually empty the rbtree - it's still pointing to nodes that werefreed.So set the rbtree's root node to NULL to avoid this warning (assignRB_ROOT).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix potential use-after-free bug when trimming capsWhen trimming the caps and just after the 'session->s_cap_lock' isreleased in ceph_iterate_session_caps() the cap maybe removed byanother thread, and when using the stale cap memory in the callbacksit will trigger use-after-free crash.We need to check the existence of the cap just after the 'ci->i_ceph_lock'being acquired. And do nothing if it's already removed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mips: bmips: BCM6358: disable RAC flush for TP1RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:[ 3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform[ 3.895011] Reserved instruction in kernel code[#1]:[ 3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0[ 3.905829] $ 0 : 00000000 10008700 00000000 77d94060[ 3.911238] $ 4 : 7fd1f088 00000000 81431cac 81431ca0[ 3.916641] $ 8 : 00000000 ffffefff 8075cd34 00000000[ 3.922043] $12 : 806f8d40 f3e812b7 00000000 000d9aaa[ 3.927446] $16 : 7fd1f068 7fd1f080 7ff559b8 81428470[ 3.932848] $20 : 00000000 00000000 55590000 77d70000[ 3.938251] $24 : 00000018 00000010[ 3.943655] $28 : 81430000 81431e60 81431f28 800157fc[ 3.949058] Hi : 00000000[ 3.952013] Lo : 00000000[ 3.955019] epc : 80015808 setup_sigcontext+0x54/0x24c[ 3.960464] ra : 800157fc setup_sigcontext+0x48/0x24c[ 3.965913] Status: 10008703 KERNEL EXL IE[ 3.970216] Cause : 00800028 (ExcCode 0a)[ 3.974340] PrId : 0002a010 (Broadcom BMIPS4350)[ 3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common[ 3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)[ 4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470[ 4.009467] 81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74[ 4.018149] 08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003[ 4.026831] ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000[ 4.035512] 77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000[ 4.044196] ...[ 4.046706] Call Trace:[ 4.049238] [<80015808>] setup_sigcontext+0x54/0x24c[ 4.054356] [<80015c70>] setup_frame+0xdc/0x124[ 4.059015] [<80016414>] do_notify_resume+0x1dc/0x288[ 4.064207] [<80011b50>] work_notifysig+0x10/0x18[ 4.069036][ 4.070538] Code: 8fc300b4 00001025 26240008
ac830004 3c048063 0c0228aa 24846a00 26240010[ 4.080686][ 4.082517] ---[ end trace 22a8edb41f5f983b ]---[ 4.087374] Kernel panic - not syncing: Fatal exception[ 4.092753] Rebooting in 1 seconds..Because the bootloader (CFE) is not initializing the Read-ahead cache properlyon the second thread (TP1). Since the RAC was not initialized properly, weshould avoid flushing it at the risk of corrupting the instruction stream asseen in the trace above.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ionic: remove WARN_ON to prevent panic_on_warnRemove unnecessary early code development check and the WARN_ONthat it uses. The irq alloc and free paths have long beencleaned up and this check shouldn't have stuck around so long.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: TC, Fix internal port memory leakThe flow rule can be splited, and the extra post_act rules are addedto post_act table. It's possible to trigger memleak when the ruleforwards packets from internal port and over tunnel, in the case that,for example, CT 'new' state offload is allowed. As int_port object isassigned to the flow attribute of post_act rule, and its refcnt isincremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() isnot called, the refcnt is never decremented, then int_port is neverfreed.The kmemleak reports the following error:unreferenced object 0xffff888128204b80 (size 64): comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s) hex dump (first 32 bytes): 01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00 ................ 98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff .wgA.....wgA.... backtrace: [<00000000e992680d>] kmalloc_trace+0x27/0x120 [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core] [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core] [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core] [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core] [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core] [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core] [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410 [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower] [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower] [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010 [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0 [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360 [<0000000082dd6c8b>] netlink_unicast+0x438/0x710 [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50 [<0000000016e92590>] sock_sendmsg+0xc5/0x190So fix this by moving int_port cleanup code to the flow attributefree helper, which is used by all the attribute free cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while usingIPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)We had a similar report [1] for probably sk_memory_allocated_add()in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fixNULL pointer dereference") fixed it by setting .memory_allocated forudplite_prot and udplitev6_prot.To fix the variant, we need to set either .sysctl_wmem_offset or.sysctl_rmem.Now UDP and UDPLITE share the same value for .memory_allocated, so weuse the same .sysctl_wmem_offset for UDP and UDPLITE.[0]:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8bRSP: 0018:ffffc90005d7f450 EFLAGS: 00010246RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0Call Trace: __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82RIP: 0023:0xf7f21579Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix memory leak in binder_init()In binder_init(), the destruction of binder_alloc_shrinker_init() is notperformed in the wrong path, which will cause memory leaks. So this commitintroduces binder_alloc_shrinker_exit() and calls it in the wrong path tofix that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix stack overflow when LRO is disabled for virtual interfacesWhen the virtual interface's feature is updated, it synchronizes theupdated feature for its own lower interface.This propagation logic should be worked as the iteration, not recursively.But it works recursively due to the netdev notification unexpectedly.This problem occurs when it disables LRO only for the team and bondinginterface type. team0 | +------+------+-----+-----+ | | | | |team1 team2 team3 ... team200If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGEevent to its own lower interfaces(team1 ~ team200).It is worked by netdev_sync_lower_features().So, the NETDEV_FEAT_CHANGE notification logic of each lower interfacework iteratively.But generated NETDEV_FEAT_CHANGE event is also sent to the upperinterface too.upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its ownlower interfaces again.lower and upper interfaces receive this event and generate thisevent again and again.So, the stack overflow occurs.But it is not the infinite loop issue.Because the netdev_sync_lower_features() updates features beforegenerating the NETDEV_FEAT_CHANGE event.Already synchronized lower interfaces skip notification logic.So, it is just the problem that iteration logic is changed to therecursive unexpectedly due to the notification mechanism.Reproducer:ip link add team0 type teamethtool -K team0 lro onfor i in {1..200}do ip link add team$i master team0 type team ethtool -K team$i lro ondoneethtool -K team0 lro offIn order to fix it, the notifier_ctx member of bonding/team is introduced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between balance and cancel/pauseSyzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe reproducer is running a balance and a cancel or pause in parallel.The way balance finishes is a bit wonky, if we were paused we need tosave the balance_ctl in the fs_info, but clear it otherwise and cleanup.However we rely on the return values being specific errors, or having acancel request or no pause request. If balance completes and returns 0,but we have a pause or cancel request we won't do the appropriatecleanup, and then the next time we try to start a balance we'll tripthis ASSERT.The error handling is just wrong here, we always want to clean up,unless we got -ECANCELLED and we set the appropriate pause flag in theexclusive op. With this patch the reproducer ran for an hour withouttripping, previously it would trip in less than a few minutes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add queue index attr to vdpa_nl_policy for nlattr length checkThe vdpa_nl_policy structure is used to validate the nlattr when parsingthe incoming nlmsg. It will ensure the attribute being described producesa valid nlattr pointer in info->attrs before entering into each handlerin vdpa_nl_ops.That is to say, the missing part in vdpa_nl_policy may lead to illegalnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.This patch adds the missing nla_policy for vdpa queue index attr to avoidsuch bugs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting quota root from the dirty cow roots listWhen disabling quotas we are deleting the quota root from the listfs_info->dirty_cowonly_roots without taking the lock that protects it,which is struct btrfs_fs_info::trans_lock. This unsynchronized listmanipulation may cause chaos if there's another concurrent manipulationof this list, such as when adding a root to it withctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe quota root from that list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix a memory leak in the LRU and LRU_PERCPU hash mapsThe LRU and LRU_PERCPU maps allocate a new element on update before locking thetarget hash table bucket. Right after that the maps try to lock the bucket.If this fails, then maps return -EBUSY to the caller without releasing theallocated element. This makes the element untracked: it doesn't belong toeither of free lists, and it doesn't belong to the hash table, so can't bere-used; this eventually leads to the permanent -ENOMEM on LRU map updates,which is unexpected. Fix this by returning the element to the local free listif bucket locking fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: fix skb leak by txs missing in AMSDUtxs may be dropped if the frame is aggregated in AMSDU. When the problemshows up, some SKBs would be hold in driver to cause network stoppedtemporarily. Even if the problem can be recovered by txs timeout handling,mt7921 still need to disable txs in AMSDU to avoid this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kheaders: Use array declaration instead of charUnder CONFIG_FORTIFY_SOURCE, memcpy() will check the size of destinationand source buffers. Defining kernel_headers_data as "char" would tripthis check. Since these addresses are treated as byte arrays, definethem as arrays (as done everywhere else).This was seen with: $ cat /sys/kernel/kheaders.tar.xz >> /dev/null detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1027! ... RIP: 0010:fortify_panic+0xf/0x20 [...] Call Trace: ikheaders_read+0x45/0x50 [kheaders] kernfs_fop_read_iter+0x1a4/0x2f0 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xferIn gl861_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach gl861_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting free space root from the dirty cow roots listWhen deleting the free space tree we are deleting the free space rootfrom the list fs_info->dirty_cowonly_roots without taking the lock thatprotects it, which is struct btrfs_fs_info::trans_lock.This unsynchronized list manipulation may cause chaos if there's anotherconcurrent manipulation of this list, such as when adding a root to itwith ctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe free space root from that list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: speed up grant-table reclaimWhen a grant entry is still in use by the remote domain, Linux must putit on a deferred list. Normally, this list is very short, becausethe PV network and block protocols expect the backend to unmap the grantfirst. However, Qubes OS's GUI protocol is subject to the constraintsof the X Window System, and as such winds up with the frontend unmappingthe window first. As a result, the list can grow very large, resultingin a massive memory leak and eventual VM freeze.To partially solve this problem, make the number of entries that the VMwill attempt to free at each iteration tunable. The default is still10, but it can be overridden via a module parameter.This is Cc: stable because (when combined with appropriate userspacechanges) it fixes a severe performance and stability problem for QubesOS users.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add preempt_count_{sub,add} into btf id deny listThe recursion check in __bpf_prog_enter* and __bpf_prog_exit*leave preempt_count_{sub,add} unprotected. When attaching trampoline tothem we get panic as follows,[ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)[ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI[ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4[ 867.843100] Call Trace:[ 867.843101] [ 867.843104] asm_exc_int3+0x3a/0x40[ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0[ 867.843135] __bpf_prog_enter_recur+0x17/0x90[ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000[ 867.843154] ? preempt_count_sub+0x1/0xa0[ 867.843157] preempt_count_sub+0x5/0xa0[ 867.843159] ? migrate_enable+0xac/0xf0[ 867.843164] __bpf_prog_exit_recur+0x2d/0x40[ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000...[ 867.843788] preempt_count_sub+0x5/0xa0[ 867.843793] ? migrate_enable+0xac/0xf0[ 867.843829] __bpf_prog_exit_recur+0x2d/0x40[ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)[ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)[ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)[ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000...That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} arecalled after prog->active is decreased.Fixing this by adding these two functions into btf ids deny list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix possible null-ptr-deref in ubi_free_volume()It willl cause null-ptr-deref in the following case:uif_init() ubi_add_volume() cdev_add() -> if it fails, call kill_volumes() device_register()kill_volumes() -> if ubi_add_volume() fails call this function ubi_free_volume() cdev_del() device_unregister() -> trying to delete a not added device, it causes null-ptr-derefSo in ubi_free_volume(), it delete devices whether they are addedor not, it will causes null-ptr-deref.Handle the error case whlie calling ubi_add_volume() to fix thisproblem. If add volume fails, set the corresponding vol to null,so it can not be accessed in kill_volumes() and release theresource in ubi_add_volume() error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: anysee: fix null-ptr-deref in anysee_master_xferIn anysee_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach anysee_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")[hverkuil: add spaces around +]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent skb corruption on frag list segmentationIan reported several skb corruptions triggered by rx-gro-list,collecting different oops alike:[ 62.624003] BUG: kernel NULL pointer dereference, address: 00000000000000c0[ 62.631083] #PF: supervisor read access in kernel mode[ 62.636312] #PF: error_code(0x0000) - not-present page[ 62.641541] PGD 0 P4D 0[ 62.644174] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 62.648629] CPU: 1 PID: 913 Comm: napi/eno2-79 Not tainted 6.4.0 #364[ 62.655162] Hardware name: Supermicro Super Server/A2SDi-12C-HLN4F, BIOS 1.7a 10/13/2022[ 62.663344] RIP: 0010:__udp_gso_segment (./include/linux/skbuff.h:2858./include/linux/udp.h:23 net/ipv4/udp_offload.c:228 net/ipv4/udp_offload.c:261net/ipv4/udp_offload.c:277)[ 62.687193] RSP: 0018:ffffbd3a83b4f868 EFLAGS: 00010246[ 62.692515] RAX: 00000000000000ce RBX: 0000000000000000 RCX: 0000000000000000[ 62.699743] RDX: ffffa124def8a000 RSI: 0000000000000079 RDI: ffffa125952a14d4[ 62.706970] RBP: ffffa124def8a000 R08: 0000000000000022 R09: 00002000001558c9[ 62.714199] R10: 0000000000000000 R11: 00000000be554639 R12: 00000000000000e2[ 62.721426] R13: ffffa125952a1400 R14: ffffa125952a1400 R15: 00002000001558c9[ 62.728654] FS: 0000000000000000(0000) GS:ffffa127efa40000(0000)knlGS:0000000000000000[ 62.736852] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 62.742702] CR2: 00000000000000c0 CR3: 00000001034b0000 CR4: 00000000003526e0[ 62.749948] Call Trace:[ 62.752498] [ 62.779267] inet_gso_segment (net/ipv4/af_inet.c:1398)[ 62.787605] skb_mac_gso_segment (net/core/gro.c:141)[ 62.791906] __skb_gso_segment (net/core/dev.c:3403 (discriminator 2))[ 62.800492] validate_xmit_skb (./include/linux/netdevice.h:4862net/core/dev.c:3659)[ 62.804695] validate_xmit_skb_list (net/core/dev.c:3710)[ 62.809158] sch_direct_xmit (net/sched/sch_generic.c:330)[ 62.813198] __dev_queue_xmit (net/core/dev.c:3805 net/core/dev.c:4210)net/netfilter/core.c:626)[ 62.821093] br_dev_queue_push_xmit (net/bridge/br_forward.c:55)[ 62.825652] maybe_deliver (net/bridge/br_forward.c:193)[ 62.829420] br_flood (net/bridge/br_forward.c:233)[ 62.832758] br_handle_frame_finish (net/bridge/br_input.c:215)[ 62.837403] br_handle_frame (net/bridge/br_input.c:298net/bridge/br_input.c:416)[ 62.851417] __netif_receive_skb_core.constprop.0 (net/core/dev.c:5387)[ 62.866114] __netif_receive_skb_list_core (net/core/dev.c:5570)[ 62.871367] netif_receive_skb_list_internal (net/core/dev.c:5638net/core/dev.c:5727)[ 62.876795] napi_complete_done (./include/linux/list.h:37./include/net/gro.h:434 ./include/net/gro.h:429 net/core/dev.c:6067)[ 62.881004] ixgbe_poll (drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:3191)[ 62.893534] __napi_poll (net/core/dev.c:6498)[ 62.897133] napi_threaded_poll (./include/linux/netpoll.h:89net/core/dev.c:6640)[ 62.905276] kthread (kernel/kthread.c:379)[ 62.913435] ret_from_fork (arch/x86/entry/entry_64.S:314)[ 62.917119] In the critical scenario, rx-gro-list GRO-ed packets are fed, via abridge, both to the local input path and to an egress device (tun).The segmentation of such packets unsafely writes to the cloned skbswith shared heads.This change addresses the issue by uncloning as needed theto-be-segmented skbs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Protect reconfiguration of sb read-write from racing writesThe reconfigure / remount code takes a lot of effort to protectfilesystem's reconfiguration code from racing writes on remountingread-only. However during remounting read-only filesystem to read-writemode userspace writes can start immediately once we clear SB_RDONLYflag. This is inconvenient for example for ext4 because we need to dosome writes to the filesystem (such as preparation of quota files)before we can take userspace writes so we are clearing SB_RDONLY flagbefore we are fully ready to accept userpace writes and syzbot has founda way to exploit this [1]. Also as far as I'm reading the codethe filesystem remount code was protected from racing writes in thelegacy mount path by the mount's MNT_READONLY flag so this is relativelynew problem. It is actually fairly easy to protect remount read-writefrom racing writes using sb->s_readonly_remount flag so let's just dothat instead of having to workaround these races in the filesystem code.[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rcar_fdp1: Fix refcount leak in probe and remove functionrcar_fcp_get() take reference, which should be balanced withrcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove andthe error paths of fdp1_probe() to fix this.[hverkuil: resolve merge conflict, remove() is now void]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix memory leak in error path of kcm_sendmsg()syzbot reported a memory leak like below:BUG: memory leakunreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [] alloc_skb include/linux/skbuff.h:1289 [inline] [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [] sock_sendmsg_nosec net/socket.c:725 [inline] [] sock_sendmsg+0x56/0xb0 net/socket.c:748 [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to appendnewly allocated skbs to 'head'. If some bytes are copied, an error occurred,and jumped to out_error label, 'last_skb' is left unmodified. A laterkcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the'head' frag_list and causing the leak.This patch fixes this issue by properly updating the last allocated skb in'last_skb'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: dump vmalloc memory info safelyCurrently, for double invoke call_rcu(), will dump rcu_head objects memoryinfo, if the objects is not allocated from the slab allocator, thevmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need tobe held, since the call_rcu() can be invoked in interrupt context,therefore, there is a possibility of spinlock deadlock scenarios.And in Preempt-RT kernel, the rcutorture test also trigger the followinglockdep warning:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 1, expected: 0RCU nest depth: 1, expected: 13 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70irq event stamp: 565512hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0Preemption disabled at:[] rcu_torture_init+0x1f13/0x2370CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 The previous patch fixes this by using the deadlock-safe best-effortversion of find_vm_area. However, in case of failure print the fact thatthe pointer was a vmalloc pointer so that we print at least something.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeIn production we were seeing a variety of WARN_ON()'s in the extent_mapcode, specifically in btrfs_drop_extent_map_range() when we have to calladd_extent_mapping() for our second split.Consider the following extent map layout PINNED [0 16K) [32K, 48K)and then we call btrfs_drop_extent_map_range for [0, 36K), withskip_pinned == true. The initial loop will have start = 0 end = 36K len = 36Kwe will find the [0, 16k) extent, but since we are pinned we will skipit, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end;em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36Klen should instead be 20K. This is a problem when we find the nextextent at [32K, 48K), we need to split this extent to leave [36K, 48k),however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len);In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52Kand now we have an invalid extent_map in the tree that potentiallyoverlaps other entries in the extent map. Even in the non-overlappingcase we will have split->start set improperly, which will cause problemswith any block related calculations.We don't actually need len in this loop, we can simply use end as ourend point, and only adjust start up when we find a pinned extent we needto skip.Adjust the logic to do this, which keeps us from inserting an invalidextent map.We only skip_pinned in the relocation case, so this is relatively rare,except in the case where you are running relocation a lot, which canhappen with auto relocation on.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to drop all dirty pages during umount() if cp_error is setxfstest generic/361 reports a bug as below:f2fs_bug_on(sbi, sbi->fsync_node_num);kernel BUG at fs/f2fs/super.c:1627!RIP: 0010:f2fs_put_super+0x3a8/0x3b0Call Trace: generic_shutdown_super+0x8c/0x1b0 kill_block_super+0x2b/0x60 kill_f2fs_super+0x87/0x110 deactivate_locked_super+0x39/0x80 deactivate_super+0x46/0x50 cleanup_mnt+0x109/0x170 __cleanup_mnt+0x16/0x20 task_work_run+0x65/0xa0 exit_to_user_mode_prepare+0x175/0x190 syscall_exit_to_user_mode+0x25/0x50 do_syscall_64+0x4c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcDuring umount(), if cp_error is set, f2fs_wait_on_all_pages() shouldnot stop waiting all F2FS_WB_CP_DATA pages to be writebacked, otherwise,fsync_node_num can be non-zero after f2fs_wait_on_all_pages() causingthis bug.In this case, to avoid deadloop in f2fs_wait_on_all_pages(), it needsto drop all dirty pages rather than redirtying them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation for lmac typeUpon physical link change, firmware reports to the kernel about thechange along with the details like speed, lmac_type_id, etc.Kernel derives lmac_type based on lmac_type_id received from firmware.In a few scenarios, firmware returns an invalid lmac_type_id, whichis resulting in below kernel panic. This patch adds the missingvalidation of the lmac_type_id field.Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 35.321595] Modules linked in:[ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted5.4.210-g2e3169d8e1bc-dirty #17[ 35.337014] Hardware name: Marvell CN103XX board (DT)[ 35.344297] Workqueue: events work_for_cpu_fn[ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)[ 35.360267] pc : strncpy+0x10/0x30[ 35.366595] lr : cgx_link_change_handler+0x90/0x180
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()Syzkaller reported the following issue:=======================================Too BIG xdp->frame_sz = 131072WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103...Call Trace: bpf_prog_4add87e5301a4105+0x1a/0x1c __bpf_prog_run include/linux/filter.h:600 [inline] bpf_prog_run_xdp include/linux/filter.h:775 [inline] bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721 netif_receive_generic_xdp net/core/dev.c:4807 [inline] do_xdp_generic+0x35c/0x770 net/core/dev.c:4866 tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043 call_write_iter include/linux/fs.h:1871 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x650/0xe40 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdxdp->frame_sz > PAGE_SIZE check was introduced in commit c8741e2bfe87("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But JesperDangaard Brouer noted that after introducing thexdp_init_buff() which all XDP driver use - it's safe to remove thischeck. The original intend was to catch cases where XDP drivers havenot been updated to use xdp.frame_sz, but that is not longer a concern(since xdp_init_buff).Running the initial syzkaller repro it was discovered that thecontiguous physical memory allocation is used for both xdp paths intun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was alsostated by Jesper Dangaard Brouer that XDP canwork on higher order pages, as long as this is contiguous physicalmemory (e.g. a page).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_sdei: Fix sleep from invalid context BUGRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altratriggers: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20sdei_cpuhp_up() is called in the STARTING hotplug section,which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entryinstead to execute the cpuhp cb later, with preemption enabled.SDEI originally got its own cpuhp slot to allow interactingwith perf. It got superseded by pNMI and this early slot is notrelevant anymore. [1]Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on thecalling CPU. It is checked that preemption is disabled for them._ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.Preemption is enabled in those threads, but their cpumask is limitedto 1 CPU.Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cbdon't trigger them.Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI callwhich acts on the calling CPU.[1]:https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:keys: Fix linking a duplicate key to a keyring's assoc_arrayWhen making a DNS query inside the kernel using dns_query(), the requestcode can in rare cases end up creating a duplicate index key in theassoc_array of the destination keyring. It is eventually found bya BUG_ON() check in the assoc_array implementation and results ina crash.Example report:[2158499.700025] kernel BUG at ../lib/assoc_array.c:652![2158499.700039] invalid opcode: 0000 [#1] SMP PTI[2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3[2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020[2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs][2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40[2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff <0f> 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f[2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282[2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005[2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000[2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000[2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28[2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740[2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000[2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0[2158499.700702] Call Trace:[2158499.700741] ? key_alloc+0x447/0x4b0[2158499.700768] ? __key_link_begin+0x43/0xa0[2158499.700790] __key_link_begin+0x43/0xa0[2158499.700814] request_key_and_link+0x2c7/0x730[2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver][2158499.700873] ? key_default_cmp+0x20/0x20[2158499.700898] request_key_tag+0x43/0xa0[2158499.700926] dns_query+0x114/0x2ca [dns_resolver][2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs][2158499.701164] ? scnprintf+0x49/0x90[2158499.701190] ? __switch_to_asm+0x40/0x70[2158499.701211] ? __switch_to_asm+0x34/0x70[2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs][2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs][2158499.701632] process_one_work+0x1f8/0x3e0[2158499.701658] worker_thread+0x2d/0x3f0[2158499.701682] ? process_one_work+0x3e0/0x3e0[2158499.701703] kthread+0x10d/0x130[2158499.701723] ? kthread_park+0xb0/0xb0[2158499.701746] ret_from_fork+0x1f/0x40The situation occurs as follows:* Some kernel facility invokes dns_query() to resolve a hostname, for example, "abcdef". The function registers its global DNS resolver cache as current->cred.thread_keyring and passes the query to request_key_net() -> request_key_tag() -> request_key_and_link().* Function request_key_and_link() creates a keyring_search_context object. Its match_data.cmp method gets set via a call to type->match_preparse() (resolves to dns_resolver_match_preparse()) to dns_resolver_cmp().* Function request_key_and_link() continues and invokes search_process_keyrings_rcu() which returns that a given key was not found. The control is then passed to request_key_and_link() -> construct_alloc_key().* Concurrently to that, a second task similarly makes a DNS query for "abcdef." and its result gets inserted into the DNS resolver cache.* Back on the first task, function construct_alloc_key() first runs __key_link_begin() to determine an assoc_array_edit operation to insert a new key. Index keys in the array are compared exactly as-is, using keyring_compare_object(). The operation ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix memory leak of iter->temp when reading trace_pipekmemleak reports: unreferenced object 0xffff88814d14e200 (size 256): comm "cat", pid 336, jiffies 4294871818 (age 779.490s) hex dump (first 32 bytes): 04 00 01 03 00 00 00 00 08 00 00 00 00 00 00 00 ................ 0c d8 c8 9b ff ff ff ff 04 5a ca 9b ff ff ff ff .........Z...... backtrace: [] __kmalloc+0x4f/0x140 [] trace_find_next_entry+0xbb/0x1d0 [] trace_print_lat_context+0xaf/0x4e0 [] print_trace_line+0x3e0/0x950 [] tracing_read_pipe+0x2d9/0x5a0 [] vfs_read+0x143/0x520 [] ksys_read+0xbd/0x160 [] do_syscall_64+0x3f/0x90 [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8when reading file 'trace_pipe', 'iter->temp' is allocated or relocatedin trace_find_next_entry() but not freed before 'trace_pipe' is closed.To fix it, free 'iter->temp' in tracing_release_pipe().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()when kmalloc() fail to allocate memory in kasprintf(), nameor full_name will be NULL, strcmp() will causenull pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix issue in verifying allow_ptr_leaksAfter we converted the capabilities of our networking-bpf program fromcap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf programfailed to start. Because it failed the bpf verifier, and the error logis "R3 pointer comparison prohibited".A simple reproducer as follows,SEC("cls-ingress")int ingress(struct __sk_buff *skb){ struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK;}Per discussion with Yonghong and Alexei [1], comparison of two packetpointers is not a pointer leak. This patch fixes it.Our local kernel is 6.1.y and we expect this fix to be backported to6.1.y, so stable is CCed.[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsit: Free cmds before session freeCommands from recovery entries are freed after session has been closed.That leads to use-after-free at command free or NPE with such call trace:Time2Retain timer expired for SID: 1, cleaning up iSCSI session.BUG: kernel NULL pointer dereference, address: 0000000000000140RIP: 0010:sbitmap_queue_clear+0x3a/0xa0Call Trace: target_release_cmd_kref+0xd1/0x1f0 [target_core_mod] transport_generic_free_cmd+0xd1/0x180 [target_core_mod] iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod] iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod] iscsit_close_session+0x13a/0x140 [iscsi_target_mod] iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod] call_timer_fn+0x24/0x140Move cleanup of recovery enrties to before session freeing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Fix oops for port->pm on uart_change_pm()Unloading a hardware specific 8250 driver can produce error "Unable tohandle kernel paging request at virtual address" about ten seconds afterunloading the driver. This happens on uart_hangup() callinguart_change_pm().Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on portspecific driver unbind") was only a partial fix. If the hardware specificdriver has initialized port->pm function, we need to clear port->pm too.Just reinitializing port->ops does not do this. Otherwise serial8250_pm()will call port->pm() instead of serial8250_do_pm().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: avoid a NULL dereference with unsupported widgetsIf an IPC4 topology contains an unsupported widget, its .module_infofield won't be set, then sof_ipc4_route_setup() will cause a kernelOops trying to dereference it. Add a check for such cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()There is a certain chance to trigger the following panic:PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48" #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62 [exception RIP: ib_alloc_mr+19] RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc] #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc] #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]The reason here is that when the server tries to create a second link,smc_llc_srv_add_link() has no protection and may add a new link tolink group. This breaks the security environment protected byllc_conf_mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()rule_locs is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrule_locs to avoid NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()The rcuscale.holdoff module parameter can be used to delay the startof rcu_scale_writer() kthread. However, the hung-task timeout willtrigger when the timeout specified by rcuscale.holdoff is greater thanhung_task_timeout_secs:runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"[ 247.071753] INFO: task rcu_scale_write:59 blocked for more than 122 seconds.[ 247.072529] Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7[ 247.073400] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 247.074331] task:rcu_scale_write state:D stack:30144 pid:59 ppid:2 flags:0x00004000[ 247.075346] Call Trace:[ 247.075660] [ 247.075965] __schedule+0x635/0x1280[ 247.076448] ? __pfx___schedule+0x10/0x10[ 247.076967] ? schedule_timeout+0x2dc/0x4d0[ 247.077471] ? __pfx_lock_release+0x10/0x10[ 247.078018] ? enqueue_timer+0xe2/0x220[ 247.078522] schedule+0x84/0x120[ 247.078957] schedule_timeout+0x2e1/0x4d0[ 247.079447] ? __pfx_schedule_timeout+0x10/0x10[ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.080591] ? __pfx_process_timeout+0x10/0x10[ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10[ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.082287] rcu_scale_writer+0x6b1/0x7f0[ 247.082773] ? mark_held_locks+0x29/0xa0[ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.084412] kthread+0x179/0x1c0[ 247.084759] ? __pfx_kthread+0x10/0x10[ 247.085098] ret_from_fork+0x2c/0x50[ 247.085433] This commit therefore replaces schedule_timeout_uninterruptible() withschedule_timeout_idle().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential oops in cifs_oplock_breakWith deferred close we can have closes that race with lease breaks,and so with the current checks for whether to send the lease response,oplock_response(), this can mean that an unmount (kill_sb) can occurjust before we were checking if the tcon->ses is valid. See below:[Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs][Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39[Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206[Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009[Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188[Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900[Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138[Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000[Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000[Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0[Fri Aug 4 04:12:50 2023] Call Trace:[Fri Aug 4 04:12:50 2023] [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0[Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0[Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0[Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150[Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50[Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30[Fri Aug 4 04:12:50 2023] To fix this change the ordering of the checks before sending the oplock_responseto first check if the openFileList is empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add missing gfx11 MQD manager callbacksmqd_stride function was introduced in commit 2f77b9a242a2("drm/amdkfd: Update MQD management on multi XCC setup")but not assigned for gfx11. Fixes a NULL dereference in debugfs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DPFixes OOPS on boards with ANX9805 DP encoders.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: release path before inode lookup during the ino lookup ioctlDuring the ino lookup ioctl we can end up calling btrfs_iget() to get aninode reference while we are holding on a root's btree. If btrfs_iget()needs to lookup the inode from the root's btree, because it's notcurrently loaded in memory, then it will need to lock another or thesame path in the same root btree. This may result in a deadlock andtrigger the following lockdep splat: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted ------------------------------------------------------ syz-executor277/5012 is trying to acquire lock: ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 but task is already holding lock: ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302 btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955 btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline] btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338 btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline] open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494 btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154 btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 fc_mount fs/namespace.c:1112 [inline] vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142 btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 do_new_mount+0x28f/0xae0 fs/namespace.c:3335 do_mount fs/namespace.c:3675 [inline] __do_sys_mount fs/namespace.c:3884 [inline] __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (btrfs-tree-01){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline] btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281 btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline] btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412 btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline] btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716 btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline] btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105 btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: avoid hanging tasks on the tx_locksyzbot sent a hung task report and Eric explains that adversarialreceiver may keep RWIN at 0 for a long time, so we are not guaranteedto make forward progress. Thread which took tx_lock and went to sleepmay not release tx_lock for hours. Use interruptible sleep wherepossible and reschedule the work if it can't take the lock.Testing: existing selftest passes
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: af9005: Fix null-ptr-deref in af9005_i2c_xferIn af9005_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9005_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_addWhile doing smcr_port_add, there maybe linkgroup add into or deletefrom smc_lgr_list.list at the same time, which may result kernel crash.So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate insmcr_port_add.The crash calltrace show below:BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] SMP NOPTICPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: GHardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014Workqueue: events smc_ib_port_event_work [smc]RIP: 0010:smcr_port_add+0xa6/0xf0 [smc]RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0PKRU: 55555554Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/pmem: Fix nvdimm registration racesA loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130...namely that the bottom half of async nvdimm device registration runsafter the CXL has already torn down the context that cxl_pmem_ctl()needs. Unlike the ACPI NFIT case that benefits from launching multiplenvdimm device registrations in parallel from those listed in the table,CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for asynchronous registration path to preclude this scenario.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible addl_desc_ptr out-of-bounds accessesSanitize possible addl_desc_ptr out-of-bounds accesses inses_enclosure_data_process().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()Syzkaller reported [1] hitting a warning after failing to allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294...Call Trace: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649...This issue is also found in older kernels (at least up to 5.10).
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: use the backlog for mirred ingressThe test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlogfor nested calls to mirred ingress") hangs our testing VMs every 10 or soruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported bylockdep.The problem as previously described by Davide (see Link) is thatif we reverse flow of traffic with the redirect (egress -> ingress)we may reach the same socket which generated the packet. And we maystill be holding its socket lock. The common solution to such deadlocksis to put the packet in the Rx backlog, rather than run the Rx pathinline. Do that for all egress -> ingress reversals, not just oncewe started to nest mirred calls.In the past there was a concern that the backlog indirection willlead to loss of error reporting / less accurate stats. But the currentworkaround does not seem to address the issue.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: veth: clear GRO when clearing XDP even when downveth sets NETIF_F_GRO automatically when XDP is enabled,because both features use the same NAPI machinery.The logic to clear NETIF_F_GRO sits in veth_disable_xdp() whichis called both on ndo_stop and when XDP is turned off.To avoid the flag from being cleared when the device is broughtdown, the clearing is skipped when IFF_UP is not set.Bringing the device down should indeed not modify its features.Unfortunately, this means that clearing is also skipped whenXDP is disabled _while_ the device is down. And there's nothingon the open path to bring the device features back into sync.IOW if user enables XDP, disables it and then brings the deviceup we'll end up with a stray GRO flag set but no NAPI instances.We don't depend on the GRO flag on the datapath, so the datapathwon't crash. We will crash (or hang), however, next time featuresare sync'ed (either by user via ethtool or peer changing its config).The GRO flag will go away, and veth will try to disable the NAPIs.But the open path never created them since XDP was off, the GRO flagwas a stray. If NAPI was initialized before we'll hang in napi_disable().If it never was we'll crash trying to stop uninitialized hrtimer.Move the GRO flag updates to the XDP enable / disable paths,instead of mixing them with the ndo_open / ndo_close paths.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: af_bluetooth: Fix deadlockAttemting to do sock_lock on .recvmsg may cause a deadlock as shownbellow, so instead of using sock_sock this uses sk_receive_queue.lockon bt_sock_ioctl to avoid the UAF:INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183Workqueue: hci0 hci_rx_workCall Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshapeFor raid456, if reshape is still in progress, then IO across reshapeposition will wait for reshape to make progress. However, for dm-raid,in following cases reshape will never make progress hence IO will hang:1) the array is read-only;2) MD_RECOVERY_WAIT is set;3) MD_RECOVERY_FROZEN is set;After commit c467e97f079f ("md/raid6: use valid sector values to determineif an I/O should wait on the reshape") fix the problem that IO acrossreshape position doesn't wait for reshape, the dm-raid testshell/lvconvert-raid-reshape.sh start to hang:[root@fedora ~]# cat /proc/979/stack[<0>] wait_woken+0x7d/0x90[<0>] raid5_make_request+0x929/0x1d70 [raid456][<0>] md_handle_request+0xc2/0x3b0 [md_mod][<0>] raid_map+0x2c/0x50 [dm_raid][<0>] __map_bio+0x251/0x380 [dm_mod][<0>] dm_submit_bio+0x1f0/0x760 [dm_mod][<0>] __submit_bio+0xc2/0x1c0[<0>] submit_bio_noacct_nocheck+0x17f/0x450[<0>] submit_bio_noacct+0x2bc/0x780[<0>] submit_bio+0x70/0xc0[<0>] mpage_readahead+0x169/0x1f0[<0>] blkdev_readahead+0x18/0x30[<0>] read_pages+0x7c/0x3b0[<0>] page_cache_ra_unbounded+0x1ab/0x280[<0>] force_page_cache_ra+0x9e/0x130[<0>] page_cache_sync_ra+0x3b/0x110[<0>] filemap_get_pages+0x143/0xa30[<0>] filemap_read+0xdc/0x4b0[<0>] blkdev_read_iter+0x75/0x200[<0>] vfs_read+0x272/0x460[<0>] ksys_read+0x7a/0x170[<0>] __x64_sys_read+0x1c/0x30[<0>] do_syscall_64+0xc6/0x230[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74This is because reshape can't make progress.For md/raid, the problem doesn't exist because register new sync_threaddoesn't rely on the IO to be done any more:1) If array is read-only, it can switch to read-write by ioctl/sysfs;2) md/raid never set MD_RECOVERY_WAIT;3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.However, I'm not sure yet how to avoid the problem in dm-raid yet. Thispatch on the one hand make sure raid_message() can't changesync_thread() through raid_message() after presuspend(), on the otherhand detect the above 3 cases before wait for IO do be done indm_suspend(), and let dm-raid requeue those IO.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: Do a runtime PM get on controllers during probemt8183-mfgcfg has a mutual dependency with genpd during the probingstage, which leads to a deadlock in the following call stack:CPU0: genpd_lock --> clk_prepare_lockgenpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()CPU1: clk_prepare_lock --> genpd_lockclk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()Do a runtime PM get at the probe function to make sure clk_register()won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,do this on all mediatek clock controller probings because we don'tbelieve this would cause any regression.Verified on MT8183 and MT8192 Chromebooks.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'The 'stream' pointer is used in dcn10_set_output_transfer_func() beforethe check if 'stream' is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid: really frozen sync_thread during suspend1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes().2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used.3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend().4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), thetest shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),and with previous fixes, the test won't hang there anymore, however, thetest will still fail and complain that ext4 is corrupted. And with thispatch, the test won't hang due to stop_sync_thread() or fail due to ext4is corrupted anymore. However, there is still a deadlock related todm-raid456 that will be fixed in following patches.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/dm-raid: don't call md_reap_sync_thread() directlyCurrently md_reap_sync_thread() is called from raid_message() directlywithout holding 'reconfig_mutex', this is definitely unsafe becausemd_reap_sync_thread() can change many fields that is protected by'reconfig_mutex'.However, hold 'reconfig_mutex' here is still problematic because thiswill cause deadlock, for example, commit 130443d60b1b ("md: refactoridle/frozen_sync_thread() to fix deadlock").Fix this problem by using stop_sync_thread() to unregister sync_thread,like md/raid did.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe corresponding netns has been dismantled.Fortunately Josef Bacik could trigger the issue more often,and could test a patch I wrote two years ago.When TCP sockets are closed, we call inet_csk_clear_xmit_timers()to 'stop' the timers.inet_csk_clear_xmit_timers() can be called from any context,including when socket lock is held.This is the reason it uses sk_stop_timer(), aka del_timer().This means that ongoing timers might finish much later.For user sockets, this is fine because each running timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare terminated before the kernel socket is released.Modules using kernel sockets close them in their netns exit()handler.Also add sock_not_owned_by_me() helper to get LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e ("net: rds: acquire refcount on TCP sockets")which attempted to solve the issue in rds only.(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)We probably can remove the check_net() tests fromtcp_out_of_resources() and __tcp_close() in the future.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip do PCI error slot reset during RAS recoveryWhy: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs: Ensure 'ib_sge list' is accessibleMove the declaration of the 'ib_sge list' variable outside the'always_invalidate' block to ensure it remains accessible for usethroughout the function.Previously, 'ib_sge list' was declared within the 'always_invalidate'block, limiting its accessibility, then caused a'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10This change ensures the variable is available for subsequent operationsthat require it.[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: do not WARN if iocg was already offlinedIn iocg_pay_debt(), warn is triggered if 'active_list' is empty, whichis intended to confirm iocg is active when it has debt. However, warncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0The warn in this situation is meaningless. Since this iocg is beingremoved, the state of the 'active_list' is irrelevant, and 'waitq_timer'is canceled after removing 'active_list' in ioc_pd_free(), which ensuresiocg is freed after iocg_waitq_timer_fn() returns.Therefore, add the check if iocg was already offlined to avoid warnwhen removing a blkcg or disk.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in:---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: Add callback function pointer check before its callIn dpu_core_irq_callback_handler() callback function pointer is compared to NULL,but then callback function is unconditionally called by this pointer.Fix this bug by adding conditional return.Found by Linux Verification Center (linuxtesting.org) with SVACE.Patchwork: https://patchwork.freedesktop.org/patch/588237/
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Fix userfaultfd_api to return EINVAL as expectedCurrently if we request a feature that is not set in the Kernel config wefail silently and return all the available features. However, the manpage indicates we should return an EINVAL.We need to fix this issue since we can end up with a Kernel warning shoulda program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel withthe config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cachefiles: cyclic allocation of msg_id to avoid reuseReusing the msg_id after a maliciously completed reopen request may causea read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3-------------------------------------------------cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done)cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6process_open_req copen 6,A.size // The expected failed copen was executed successfullyExpect copen to fail, and when it does, it closes fd, which sets theobject to close, and then close triggers reopen again. However, due tomsg_id reuse resulting in a successful copen, the anonymous fd is notclosed until the daemon exits. Therefore read requests waiting for reopento complete may trigger hung task.To avoid this issue, allocate the msg_id cyclically to avoid reusing themsg_id for a very short duration of time.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid to reuse `hctx` not removed from cpuhp callback listIf the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,otherwise use-after-free may be triggered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/imx-irqsteer: Handle runtime power management correctlyThe power domain is automatically activated from clk_prepare(). However, oncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokessleeping functions, which triggers the 'scheduling while atomic' bug in thecontext switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chipcallbacks and handle power management in them as they are invoked fromnon-atomic context.[ tglx: Rewrote change log, added Fixes tag ]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: flow_dissector: use DEBUG_NET_WARN_ON_ONCEThe following splat is easy to reproduce upstream as well as in -stablekernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net")but this complementary fix has been also suggested by Willem de Bruijnand it can be easily backported to -stable kernel which consists inusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splatgiven __skb_get_hash() is used by the nftables tracing infrastructure toto identify packets in traces.[69133.561393] ------------[ cut here ]------------[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/[...][69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ffff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28[69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0[69133.562040] Call Trace:[69133.562044] [69133.562049] ? __warn+0x9f/0x1a0[ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860[...][ 1211.841496] ? bpf_flow_dissect+0x160/0x160[ 1211.841753] __skb_get_hash+0x97/0x280[ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230[ 1211.841776] ? mod_find+0xbf/0xe0[ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0[ 1211.841798] ? bpf_ksym_find+0x56/0xe0[ 1211.841807] ? __rcu_read_unlock+0x2a/0x70[ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables][ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables][ 1211.841964] ? get_stack_info+0x2b/0x80[ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables][ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()Instead of getting the epc_features from pci_epc_get_features() API, usethe cached pci_epf_test::epc_features value to avoid the NULL check. Sincethe NULL check is already performed in pci_epf_test_bind(), having one morecheck in pci_epf_test_core_init() is redundant and it is not possible tohit the NULL pointer dereference.Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"flag"), 'epc_features' got dereferenced without the NULL check, leading tothe following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)Thus, remove the redundant NULL check and also use the epc_features::{msix_capable/msi_capable} flags directly to avoid local variables.[kwilczynski: commit log]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/uv: Don't call folio_wait_writeback() without a folio referencefolio_wait_writeback() requires that no spinlocks are held and thata folio reference is held, as documented. After we dropped the PTL, thefolio could get freed concurrently. So grab a temporary reference.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: wait for previous gc cycles when removing portsyzbot hit a use-after-free[1] which is caused because the bridge doesn'tmake sure that all previous garbage has been collected when removing aport. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still runningMake sure all previous gc cycles have finished by using flush_work beforefreeing the port.[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don't bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don't do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Prevent unmapping active read buffersThe kms paths keep a persistent map active to read and compare the cursorbuffer. These maps can race with each other in simple scenario where:a) buffer "a" mapped for updateb) buffer "a" mapped for comparec) do the compared) unmap "a" for comparee) update the cursorf) unmap "a" for updateAt step "e" the buffer has been unmapped and the read contents is bogus.Prevent unmapping of active read buffers by simply keeping a count ofhow many paths have currently active maps and unmap only when the countreaches 0.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event->mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] [ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: call nf_unregister_net_hooks() soonersyzbot found an use-after-free Read in ila_nf_input [1]Issue here is that ila_xlat_exit_net() frees the rhashtable,then call nf_unregister_net_hooks().It should be done in the reverse way, with a synchronize_rcu().This is a good match for a pre_exit() method.[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)page_type: 0xbfffffff(buddy)raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: heaps: Fix off-by-one in CMA heap fault handlerUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:Don't track CMA dma-buf pages under RssFile") it was possible to obtaina mapping larger than the buffer size via mremap and bypass the overflowcheck in dma_buf_mmap_internal. When using such a mapping to attempt tofault past the end of the buffer, the CMA heap fault handler also checksthe fault offset against the buffer size, but gets the boundary wrong by1. Fix the boundary check so that we don't read off the end of the pagesarray and insert an arbitrary page in the mapping.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: Fix uaf in __timer_delete_syncThere are two paths to access mptcp_pm_del_add_timer, result in a racecondition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry)In remove_anno_list_by_saddr(running on CPU2), after leaving the criticalzone protected by "pm.lock", the entry will be released, which leads to theoccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).Keeping a reference to add_timer inside the lock, and callingsk_stop_timer_sync() with this reference, instead of "entry->add_timer".Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,do not directly access any members of the entry outside the pm lock, whichcan avoid similar "entry->x" uaf.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: stm32/cryp - call finalize with bh disabledThe finalize operation in interrupt mode produce a produces a spinlockrecursion warning. The reason is the fact that BH must be disabledduring this process.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy->enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late. After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: change the order of rate limitsICMP messages are ratelimited :After the blamed commits, the two rate limiters are applied in this order:1) host wide ratelimit (icmp_global_allow())2) Per destination ratelimit (inetpeer based)In order to avoid side-channels attacks, we need to applythe per destination check first.This patch makes the following change :1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3)2) The per destination limit is checked/updated. This might add a new node in inetpeer tree.3) icmp_global_consume() consumes tokens if prior operations succeeded.This means that host wide ratelimit is still effectivein keeping inetpeer tree small even under DDOS.As a bonus, I removed icmp_global.lock as the fast pathcan use a lock-free operation.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: handle overlapped pclusters out of crafted images properlysyzbot reported a task hang issue due to a deadlock case where it iswaiting for the folio lock of a cached folio that will be used forcache I/Os.After looking into the crafted fuzzed image, I found it's formed withseveral overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384...Here, extent 0/1 are physically overlapped although it's entirely_impossible_ for normal filesystem images generated by mkfs.First, managed folios containing compressed data will be marked asup-to-date and then unlocked immediately (unlike in-place folios) whencompressed I/Os are complete. If physical blocks are not submitted inthe incremental order, there should be separate BIOs to avoid dependencyissues. However, the current code mis-arranges z_erofs_fill_bio_vec()and BIO submission which causes unexpected BIO waits.Second, managed folios will be connected to their own pclusters forefficient inter-queries. However, this is somewhat hard to implementeasily if overlapped big pclusters exist. Again, these only appear infuzzed images so let's simply fall back to temporary short-lived pagesfor correctness.Additionally, it justifies that referenced managed folios cannot betruncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidyup `struct z_erofs_bvec`") for simplicity although it shouldn't be anydifference.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/tracing: Fix a potential TP_printk UAFThe commitafd2627f727b ("tracing: Check "%s" dereference via the field and not the TP_printk format")exposes potential UAFs in the xe_bo_move trace event.Fix those by avoiding dereferencing thexe_mem_type_to_name[] array at TP_printk time.Since some code refactoring has taken place, explicit backporting maybe needed for kernels older than 6.10.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null-initialized variables[WHAT & HOW]drr_timing and subvp_pipe are initialized to null and they are notalways assigned new values. It is necessary to check for null beforedereferencing.This fixes 2 FORWARD_NULL issues reported by Coverity.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hwThis commit addresses a potential null pointer dereference issue in the`dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` isnull.The fix adds a check to ensure `dc->clk_mgr` is not null beforeaccessing its functions. This prevents a potential null pointerdereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_startIn sctp_listen_start() invoked by sctp_inet_listen(), it should set thesk_state back to CLOSED if sctp_autobind() fails due to whatever reason.Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuseis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash willbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hashis NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious 'GSO' packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix possible crash on mgmt_index_removedIf mgmt_index_removed is called while there are commands queued oncmd_sync it could lead to crashes like the bellow trace:0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]So while handling mgmt_index_removed this attempts to dequeuecommands passed as user_data to cmd_sync.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prevent nf_skb_duplicated corruptionsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could writeper-cpu variable nf_skb_duplicated in an unsafe way [1].Disabling preemption as hinted by the splat is not enough,we have to disable soft interrupts as well.[1]BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f4ce4f7def9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gso: fix udp gso fraglist segmentation after pull from frag_listDetect gso fraglist skbs with corrupted geometry (see below) andpass these to skb_segment instead of skb_segment_list, as the firstcan segment them correctly.Valid SKB_GSO_FRAGLIST skbs- consist of two or more segments- the head_skb holds the protocol headers plus first gso_size- one or more frag_list skbs hold exactly one segment- all but the last must be gso_sizeOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) canmodify these skbs, breaking these invariants.In extreme cases they pull all data into skb linear. For UDP, thiscauses a NULL ptr deref in __udpv4_gso_segment_list_csum atudp_hdr(seg->next)->dest.Detect invalid geometry due to pull, by checking head_skb size.Don't just drop, as this may blackhole a destination. Convert to beable to pass to regular skb_segment.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix integer overflow in BLKSECDISCARDI independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard()but for secure erase.Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r);will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: improve shutdown sequenceAlexander Sverdlin presents 2 problems during shutdown with thelan9303 driver. One is specific to lan9303 and the other just happensto reproduce there.The first problem is that lan9303 is unique among DSA drivers in that itcalls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown,not remove):phy_state_machine()-> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata()But we never stop the phy_state_machine(), so it may continue to runafter dsa_switch_shutdown(). Our common pattern in all DSA drivers isto set drvdata to NULL to suppress the remove() method that may comeafterwards. But in this case it will result in an NPD.The second problem is that the way in which we setdp->conduit->dsa_ptr = NULL; is concurrent with receive packetprocessing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL,but afterwards, rather than continuing to use that non-NULL value,dev->dsa_ptr is dereferenced again and again without NULL checks:dsa_conduit_find_user() and many other places. In between dereferences,there is no locking to ensure that what was valid once continues to bevalid.Both problems have the common aspect that closing the conduit interfacesolves them.In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWNevent in dsa_user_netdevice_event() which closes user ports as well.dsa_port_disable_rt() calls phylink_stop(), which synchronously stopsthe phylink state machine, and ds->ops->phy_read() will thus no longercall into the driver after this point.In the second case, dev_close(conduit) should do this, as perDocumentation/networking/driver.rst:| Quiescence| ----------|| After the ndo_stop routine has been called, the hardware must| not receive or transmit any data. All in flight packets must| be aborted. If necessary, poll or wait for completion of| any reset commands.So it should be sufficient to ensure that later, when we zeroizeconduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() callon this conduit.The addition of the netif_device_detach() function is to ensure thatioctls, rtnetlinks and ethtool requests on the user ports no longerpropagate down to the driver - we're no longer prepared to handle them.The race condition actually did not exist when commit 0650bf52b31f("net: dsa: be compatible with masters which unregister on shutdown")first introduced dsa_switch_shutdown(). It was created later, when westopped unregistering the user interfaces from a bad spot, and we justreplaced that sequence with a racy zeroization of conduit->dsa_ptr(one which doesn't ensure that the interfaces aren't up).
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: dax: fix overflowing extents beyond inode size when partially writingThe dax_iomap_rw() does two things in each iteration: map written blocksand copy user data to blocks. If the process is killed by user(See signalhandling in dax_iomap_iter()), the copied data will be returned and addedon inode size, which means that the length of written extents may exceedthe inode size, then fsck will fail. An example is given as:dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2Mfsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?Fix the problem by truncating extents if the written length is smallerthan expected.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: do not delay dst_entries_add() in dst_release()dst_entries_add() uses per-cpu data that might be freed at netnsdismantle from ip6_route_net_exit() calling dst_entries_destroy()Before ip6_route_net_exit() can be called, we release allthe dsts associated with this netns, via calls to dst_release(),which waits an rcu grace period before calling dst_destroy()dst_entries_add() use in dst_destroy() is racy, becausedst_entries_destroy() could have been called already.Decrementing the number of dsts must happen sooner.Notes:1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this.2) There is also discussion about removing this count of dst, which might happen in future kernels.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: avoid NFPROTO_UNSPEC where neededsyzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packetprocessing. As this is only useful to restrict locally terminatingTCP/UDP traffic, register this for ipv4 and ipv6 family only.Pablo points out that this is a general issue, direct users of theset/getsockopt interface can call into targets/matches that were onlyintended for use with ip(6)tables.Check all UNSPEC matches and targets for similar issues:- matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area.- targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE.Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, asthey are provided for use by ip(6)tables.The MARK target is also used by arptables, so register for NFPROTO_ARP too.While at it, bail out if connbytes fails to enable the correspondingconntrack family.This change passes the selftests in iptables.git.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: accept TCA_STAB only for root qdiscMost qdiscs maintain their backlog using qdisc_pkt_len(skb)on the assumption it is invariant between the enqueue()and dequeue() handlers.Unfortunately syzbot can crash a host rather easily usinga TBF + SFQ combination, with an STAB on SFQ [1]We can't support TCA_STAB on arbitrary level, this wouldrequire to maintain per-qdisc storage.[1][ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 88.798611] #PF: supervisor read access in kernel mode[ 88.799014] #PF: error_code(0x0000) - not-present page[ 88.799506] PGD 0 P4D 0[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00All code======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ...Code starting with the faulting instruction=========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ...[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0[ 88.808165] Call Trace:[ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: handle consistently DSS corruptionBugged peer implementation can send corrupted DSS options, consistentlyhitting a few warning in the data path. Use DEBUG_NET assertions, toavoid the splat on some builds and handle consistently the error, dumpingrelated MIBs and performing fallback and/or reset according to thesubflow type.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/swapfile: skip HugeTLB pages for unuse_vmaI got a bad pud error and lost a 1GB HugeTLB when calling swapoff. Theproblem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)We can tell that pud_clear_bad is called by pud_none_or_clear_bad inunuse_pud_range() by ftrace. And therefore the HugeTLB pages will neverbe freed because we lost it from page table. We can skip HugeTLB pagesfor unuse_vma to fix it.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: propagate directory read errors from nilfs_find_entry()Syzbot reported that a task hang occurs in vcs_open() during a fuzzingtest for nilfs2.The root cause of this problem is that in nilfs_find_entry(), whichsearches for directory entries, ignores errors when loading a directorypage/folio via nilfs_get_folio() fails.If the filesystem images is corrupted, and the i_size of the directoryinode is large, and the directory page/folio is successfully read butfails the sanity check, for example when it is zero-filled,nilfs_check_folio() may continue to spit out error messages in bursts.Fix this issue by propagating the error to the callers when loading apage/folio fails in nilfs_find_entry().The current interface of nilfs_find_entry() and its callers is outdatedand cannot propagate error codes such as -EIO and -ENOMEM returned vianilfs_find_entry(), so fix it together.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix crash when config small gso_max_size/gso_ipv4_max_sizeConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflowin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,because sk->sk_gso_max_size would be much bigger than device limits.Call Trace:tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs)Add check for the minimum value of gso_max_size and gso_ipv4_max_size.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when uninstalling driverWhen the driver is uninstalled and the VF is disabled concurrently, akernel crash occurs. The reason is that the two actions call functionpci_disable_sriov(). The num_VFs is checked to determine whether torelease the corresponding resources. During the second calling, num_VFsis not 0 and the resource release function is called. However, thecorresponding resource has been released during the first invoking.Therefore, the problem occurs:[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020...[15278.131557][T50670] Call trace:[15278.134686][T50670] klist_put+0x28/0x12c[15278.138682][T50670] klist_del+0x14/0x20[15278.142592][T50670] device_del+0xbc/0x3c0[15278.146676][T50670] pci_remove_bus_device+0x84/0x120[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c[15278.162485][T50670] sriov_disable+0x50/0x11c[15278.166829][T50670] pci_disable_sriov+0x24/0x30[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3][15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge][15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30[15278.193848][T50670] invoke_syscall+0x50/0x11c[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164[15278.203837][T50670] do_el0_svc+0x34/0xcc[15278.207834][T50670] el0_svc+0x20/0x30For details, see the following figure. rmmod hclge disable VFs----------------------------------------------------hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock();In this patch, when driver is removing, we get the device_lock()to protect num_VFs, just like sriov_numvfs_store().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_dp: Fix integer overflow in zynqmp_dp_rate_get()This patch fixes a potential integer overflow in the zynqmp_dp_rate_get()The issue comes up when the expressiondrm_dp_bw_code_to_link_rate(dp->test.bw_code) * 10000 is evaluated using 32-bitNow the constant is a compatible 64-bit type.Resolves coverity issues: CID 1636340 and CID 1635811
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32values that come from the user via the submit_lookup_cmds() function.This addition could lead to an integer wrapping bug so use size_add()to prevent that.Patchwork: https://patchwork.freedesktop.org/patch/624696/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in intel_hdcp_get_capabilitySometimes during hotplug scenario or suspend/resume scenario encoder isnot always initialized when intel_hdcp_get_capability adda check to avoid kernel null pointer dereference.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix 6 GHz scan constructionIf more than 255 colocated APs exist for the set of allAPs found during 2.4/5 GHz scanning, then the 6 GHz scanconstruction will loop forever since the loop variablehas type u8, which can never reach the number found whenthat's bigger than 255, and is stored in a u32 variable.Also move it into the loops to have a smaller scope.Using a u32 there is fine, we limit the number of APs inthe scan list and each has a limit on the number of RNRentries due to the frame size. With a limit of 1000 scanresults, a frame size upper bound of 4096 (really it'smore like ~2300) and a TBTT entry size of at least 11,we get an upper bound for the number of ~372k, well inthe bounds of a u32.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()In mtk_crtc_create(), if the call to mbox_request_channel() fails then weset the "mtk_crtc->cmdq_client.chan" pointer to NULL. In that situation,we do not call cmdq_pkt_create().During the cleanup, we need to check if the "mtk_crtc->cmdq_client.chan"is NULL first before calling cmdq_pkt_destroy(). Callingcmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() andit will result in a NULL pointer dereference.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/pmc: Detect when STB is not availableLoading the amd_pmc module as: amd_pmc enable_stb=1...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340Further debugging reveals that this occurs when the requests forS2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0,indicating that the STB is inaccessible. To prevent the ioremapwarning and provide clarity to the user, handle the invalid addressand display an error message.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix lock recursionafs_wake_up_async_call() can incur lock recursion. The problem is that itis called from AF_RXRPC whilst holding the ->notify_lock, but it tries totake a ref on the afs_call struct in order to pass it to a work queue - butif the afs_call is already queued, we then have an extraneous ref that mustbe put... calling afs_put_call() may call back down into AF_RXRPC throughrxrpc_kernel_shutdown_call(), however, which might try taking the->notify_lock again.This case isn't very common, however, so defer it to a workqueue. The oopslooks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: defer partition scanningWe need to suppress the partition scan from occuring within thecontroller's scan_work context. If a path error occurs here, the IO willwait until a path becomes available or all paths are torn down, but thataction also occurs within scan_work, so it would deadlock. Defer thepartion scan to a different context that does not block scan_work.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free of network namespace.Recently, we got a customer report that CIFS triggers oops whilereconnecting to a server. [0]The workload runs on Kubernetes, and some pods mount CIFS serversin non-root network namespaces. The problem rarely happened, butit was always while the pod was dying.The root cause is wrong reference counting for network namespace.CIFS uses kernel sockets, which do not hold refcnt of the netns thatthe socket belongs to. That means CIFS must ensure the socket isalways freed before its netns; otherwise, use-after-free happens.The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFSWe can reproduce the issue quickly with the script [1] below and seethe splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.When the socket is TCP, it is hard to guarantee the netns lifetimewithout holding refcnt due to async timers.Let's hold netns refcnt for each socket as done for SMC in commit9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").Note that we need to move put_net() from cifs_put_tcp_session() toclean_demultiplex_info(); otherwise, __sock_create() still could touch afreed netns while cifsd tries to reconnect from cifs_demultiplex_thread().Also, maybe_get_net() cannot be put just before __sock_create() becausethe code is not under RCU and there is a small chance that the sameaddress happened to be reallocated to another netns.[0]:CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...CIFS: Serverclose failed 4 times, giving upUnable to handle kernel paging request at virtual address 14de99e461f84a07Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0[14de99e461f84a07] address between user and kernel address rangesInternal error: Oops: 0000000096000004 [#1] SMPModules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfsCPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : fib_rules_lookup+0x44/0x238lr : __fib_lookup+0x64/0xbcsp : ffff8000265db790x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerWhen hvs is released, there is a possibility that vsk->trans may notbe initialized to NULL, which could lead to a dangling pointer.This issue is resolved by initializing vsk->trans to NULL.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix NULL pointer dereference in alloc_pages_bulk_noprofWe triggered a NULL pointer dereference for ac.preferred_zoneref->zone inalloc_pages_bulk_noprof() when the task is migrated between cpusets.When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be¤t->mems_allowed. when first_zones_zonelist() is called to findpreferred_zoneref, the ac->nodemask may be modified concurrently if thetask is migrated between different cpusets. Assuming we have 2 NUMA Node,when traversing Node1 in ac->zonelist, the nodemask is 2, and whentraversing Node2 in ac->zonelist, the nodemask is 1. As a result, theac->preferred_zoneref points to NULL zone.In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds aallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leadingto NULL pointer dereference.__alloc_pages_noprof() fixes this issue by checking NULL pointer in commitea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") andcommit df76cee6bbeb ("mm, page_alloc: remove redundant checks from allocfastpath").To fix it, check NULL pointer for preferred_zoneref->zone.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio/vsock: Fix accept_queue memory leakAs the final stages of socket destruction may be delayed, it is possiblethat virtio_transport_recv_listen() will be called after the accept_queuehas been flushed, but before the SOCK_DONE flag has been set. As a result,sockets enqueued after the flush would remain unremoved, leading to amemory leak.vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK(!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) releaseclose_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound releaseIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() duringsocket destruction.unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: CT: Fix null-ptr-deref in add rule err flowIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()callback returns error, zone_rule->attr is used uninitiated. Fix it touse attr which has the needed pointer value.Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]... Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fs, lock FTE when checking if activeThe referenced commits introduced a two-step process for deleting FTEs:- Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE.- Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.However, this approach encounters a race condition if a rule with the samematch value is added simultaneously. In this scenario, fs_core may set thehardware deletion function to NULL prematurely, causing a panic duringsubsequent rule deletions.To prevent this, ensure the active flag of the FTE is checked under a lock,which will prevent the fs_core layer from attaching a new steering rule toan FTE that is in the process of deletion.[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func[ 438.968205] ------------[ cut here ]------------[ 438.968654] refcount_t: decrement hit 0; leaking memory.[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower][ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 438.986507] Call Trace:[ 438.986799] [ 438.987070] ? __warn+0x7d/0x110[ 438.987426] ? refcount_warn_saturate+0xfb/0x110[ 438.987877] ? report_bug+0x17d/0x190[ 438.988261] ? prb_read_valid+0x17/0x20[ 438.988659] ? handle_bug+0x53/0x90[ 438.989054] ? exc_invalid_op+0x14/0x70[ 438.989458] ? asm_exc_invalid_op+0x16/0x20[ 438.989883] ? refcount_warn_saturate+0xfb/0x110[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core][ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core][ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core][ 438.992054] ? xas_load+0x9/0xb0[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core][ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core][ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core][ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core][ 438.994728] tc_setup_cb_destroy+0xb9/0x190[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower][ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower][ 438.996105] tc_new_tfilter+0x347/0xbc0[ 438.996503] ? __---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: cope racing subflow creation in mptcp_rcv_space_adjustAdditional active subflows - i.e. created by the in kernel pathmanager - are included into the subflow list before starting the3whs.A racing recvmsg() spooling data received on an already establishedsubflow would unconditionally call tcp_cleanup_rbuf() on all thecurrent subflows, potentially hitting a divide by zero error onthe newly created ones.Explicitly check that the subflow is in a suitable state beforeinvoking tcp_cleanup_rbuf().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_dirty_buffer tracepointWhen using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()may cause a NULL pointer dereference, or a general protection fault whenKASAN is enabled.This happens because, since the tracepoint was added inmark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_devregardless of whether the buffer head has a pointer to a block_devicestructure.In the current implementation, nilfs_grab_buffer(), which grabs a bufferto read (or create) a block of metadata, including b-tree node blocks,does not set the block device, but instead does so only if the buffer isnot in the "uptodate" state for each of its caller block readingfunctions. However, if the uptodate flag is set on a folio/page, and thebuffer heads are detached from it by try_to_free_buffers(), and new bufferheads are then attached by create_empty_buffers(), the uptodate flag maybe restored to each buffer without the block device being set tobh->b_bdev, and mark_buffer_dirty() may be called later in that state,resulting in the bug mentioned above.Fix this issue by making nilfs_grab_buffer() always set the block deviceof the super block structure to the buffer head, regardless of the stateof the buffer's uptodate flag.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_touch_buffer tracepointPatch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".This series fixes null pointer dereference bugs that occur when usingnilfs2 and two block-related tracepoints.This patch (of 2):It has been reported that when using "block:block_touch_buffer"tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes aNULL pointer dereference, or a general protection fault when KASAN isenabled.This happens because since the tracepoint was added in touch_buffer(), itreferences the dev_t member bh->b_bdev->bd_dev regardless of whether thebuffer head has a pointer to a block_device structure. In the currentimplementation, the block_device structure is set after the functionreturns to the caller.Here, touch_buffer() is used to mark the folio/page that owns the bufferhead as accessed, but the common search helper for folio/page used by thecaller function was optimized to mark the folio/page as accessed when itwas reimplemented a long time ago, eliminating the need to calltouch_buffer() here in the first place.So this solves the issue by eliminating the touch_buffer() call itself.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKENHide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable supportfor virtualizing Intel PT via guest/host mode unless BROKEN=y. There aremyriad bugs in the implementation, some of which are fatal to the guest,and others which put the stability and health of the host at risk.For guest fatalities, the most glaring issue is that KVM fails to ensuretracing is disabled, and *stays* disabled prior to VM-Enter, which isnecessary as hardware disallows loading (the guest's) RTIT_CTL if tracingis enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0.On the host side, KVM doesn't validate the guest CPUID configurationprovided by userspace, and even worse, uses the guest configuration todecide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuringguest CPUID to enumerate more address ranges than are supported in hardwarewill result in KVM trying to passthrough, save, and load non-existent MSRs,which generates a variety of WARNs, ToPA ERRORs in the host, a potentialdeadlock, etc.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: fastmap: Fix duplicate slab cache names while attachingSince commit 4c39529663b9 ("slab: Warn on duplicate cache names whenDEBUG_VM=y"), the duplicate slab cache names can be detected and akernel WARNING is thrown out.In UBI fast attaching process, alloc_ai() could be invoked twicewith the same slab cache name 'ubi_aeb_slab_cache', which will triggerfollowing warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0The problem could be easily reproduced by loading UBI device by fastmapwith CONFIG_DEBUG_VM=y.Fix it by using different slab names for alloc_ai() callers.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: make sure cache entry active before cache_showThe function `c_show` was called with protection from RCU. This onlyensures that `cp` will not be freed. Therefore, the reference count for`cp` can drop to zero, which will trigger a refcount use-after-freewarning when `cache_get` is called. To resolve this issue, use`cache_get_rcu` to ensure that `cp` remains active.------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 7 PID: 822 at lib/refcount.c:25refcount_warn_saturate+0xb1/0x120CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb1/0x120Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Add sanity NULL check for the default mmap fault handlerA driver might allow the mmap access before initializing itsruntime->dma_area properly. Add a proper NULL check before passing tovirt_to_page() for avoiding a panic.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display:Add null check for pipe_ctx->plane_state in dcn20_program_pipe")partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: bsg: Set bsg_queue to NULL after removalCurrently, this does not cause any issues, but I believe it is necessary toset bsg_queue to NULL after removing it to prevent potential use-after-free(UAF) access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Play nice with protected guests in complete_hypercall_exit()Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bithypercall when completing said hypercall. For guests with protected state,e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bitmode as the vCPU state needed to detect 64-bit mode is unavailable.Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGEhypercall via VMGEXIT trips the WARN: ------------[ cut here ]------------ WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm] Modules linked in: kvm_amd kvm ... [last unloaded: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470 Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024 RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm] kvm_vcpu_ioctl+0x54f/0x630 [kvm] __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_kms: Unplug DRM device before removalPrevent userspace accesses to the DRM device from causinguse-after-frees by unplugging the device before we remove it. Thiscauses any further userspace accesses to result in an error withoutfurther calls into this driver's internals.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xferThe AD7923 was updated to support devices with 8 channels, but the sizeof tx_buf and ring_xfer was not increased accordingly, leading to apotential buffer overflow in ad7923_update_scan_mode().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Filter invalid inodes with missing lookup functionAdd a check to the ovl_dentry_weird() function to prevent theprocessing of directory inodes that lack the lookup function.This is important because such inodes can cause errors in overlayfswhen passed to the lowerstack.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Ensure power suppliers be suspended before detach themThe power suppliers are always requested to suspend asynchronously,dev_pm_domain_detach() requires the caller to ensure propersynchronization of this function with power management callbacks.otherwise the detach may led to kernel panic, like below:[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[ 1457.116777] Mem abort info:[ 1457.119589] ESR = 0x0000000096000004[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits[ 1457.128692] SET = 0, FnV = 0[ 1457.131764] EA = 0, S1PTW = 0[ 1457.134920] FSC = 0x04: level 0 translation fault[ 1457.139812] Data abort info:[ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec][ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)[ 1457.199236] Workqueue: pm pm_runtime_work[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290[ 1457.214886] lr : __rpm_callback+0x48/0x1d8[ 1457.218968] sp : ffff80008250bc50[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000[ 1457.293510] Call trace:[ 1457.295946] genpd_runtime_suspend+0x20/0x290[ 1457.300296] __rpm_callback+0x48/0x1d8[ 1457.304038] rpm_callback+0x6c/0x78[ 1457.307515] rpm_suspend+0x10c/0x570[ 1457.311077] pm_runtime_work+0xc4/0xc8[ 1457.314813] process_one_work+0x138/0x248[ 1457.318816] worker_thread+0x320/0x438[ 1457.322552] kthread+0x110/0x114[ 1457.325767] ret_from_fork+0x10/0x20
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix crash in the probe error path when using pollingIf an error occurs in the probe() function, we should remove the pollingtimer that was alarmed earlier, otherwise the timer is called witharguments that are already freed, which results in a crash.------------[ cut here ]------------WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268Modules linked in:CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226Hardware name: Diasom DS-RK3568-SOM-EVB (DT)pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __run_timers+0x244/0x268lr : __run_timers+0x1d4/0x268sp : ffffff80eff2baf0x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffffx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003ex14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Set video drvdata before register video deviceThe video drvdata should be set before the video device is registered,otherwise video_drvdata() may return NULL in the open() file ops, and ledto oops.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ref-verify: fix use-after-free after invalid ref actionAt btrfs_ref_tree_mod() after we successfully inserted the new ref entry(local variable 'ref') into the respective block entry's rbtree (localvariable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,we error out and free the ref entry without removing it from the blockentry's rbtree. Then in the error path of btrfs_ref_tree_mod() we callbtrfs_free_ref_cache(), which iterates over all block entries and thencalls free_block_entry() for each one, and there we will trigger ause-after-free when we are called against the block entry to which weadded the freed ref entry to its rbtree, since the rbtree still pointsto the block entry, as we didn't remove it from the rbtree before freeingit in the error path at btrfs_ref_tree_mod(). Fix this by removing thenew ref entry from the rbtree before freeing it.Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix warning in migrate_enable for boosted tasksWhen running the following command:while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quietdonea warning is eventually triggered:WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794setup_new_dl_entity+0x13e/0x180...Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92bThis warning occurs because set_cpus_allowed dequeues and enqueues taskswith the ENQUEUE_RESTORE flag set. If the task is boosted, the warningis triggered. A boosted task already had its parameters set byrt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,hence the WARN_ON call.Check if we are requeueing a boosted task and avoid callingsetup_new_dl_entity if that's the case.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/tctx: work around xa_store() allocation error issuesyzbot triggered the following WARN_ON:WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51which is theWARN_ON_ONCE(!xa_empty(&tctx->xa));sanity check in __io_uring_free() when a io_uring_task is going throughits final put. The syzbot test case includes injecting memory allocationfailures, and it very much looks like xa_store() can fail one of itsmemory allocations and end up with ->head being non-NULL even though noentries exist in the xarray.Until this issue gets sorted out, work around it by attempting toiterate entries in our xarray, and WARN_ON_ONCE() if one is found.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Add cond_resched() for no forced preemption modelFor no forced preemption model kernel, in the scenario where theexpander is connected to 12 high performance SAS SSDs, the followingcall trace may occur:[ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211][ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)[ 214.575224][ C240] pc : fput_many+0x8c/0xdc[ 214.579480][ C240] lr : fput+0x1c/0xf0[ 214.583302][ C240] sp : ffff80002de2b900[ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000[ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000[ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000[ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001[ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000[ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000[ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0[ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff[ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c[ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0[ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001[ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080[ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554[ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020[ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8[ 214.677191][ C240] Call trace:[ 214.680320][ C240] fput_many+0x8c/0xdc[ 214.684230][ C240] fput+0x1c/0xf0[ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc[ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140[ 214.696917][ C240] bio_endio+0x160/0x1bc[ 214.701001][ C240] blk_update_request+0x1c8/0x3bc[ 214.705867][ C240] scsi_end_request+0x3c/0x1f0[ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0[ 214.715249][ C240] scsi_finish_command+0x104/0x140[ 214.720200][ C240] scsi_softirq_done+0x90/0x180[ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70[ 214.730016][ C240] scsi_mq_done+0x48/0xac[ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas][ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw][ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw][ 214.752179][ C240] irq_thread_fn+0x34/0xa4[ 214.756435][ C240] irq_thread+0xc4/0x130[ 214.760520][ C240] kthread+0x108/0x13c[ 214.764430][ C240] ret_from_fork+0x10/0x18This is because in the hisi_sas driver, both the hardware interrupthandler and the interrupt thread are executed on the same CPU. In theperformance test scenario, function irq_wait_for_interrupt() will alwaysreturn 0 if lots of interrupts occurs and the CPU will be continuouslyconsumed. As a result, the CPU cannot run the watchdog thread. When thewatchdog time exceeds the specified time, call trace occurs.To fix it, add cond_resched() to execute the watchdog thread.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab's lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock's type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn't support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn't have the problem, so keptit as---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add a check to prevent array-index-out-of-bounds in dbAdjTreeWhen the value of lp is 0 at the beginning of the for loop, it willbecome negative in the next assignment and we should bail out.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in jfs_readdirThe stbl might contain some invalid values. Added a check toreturn error code in that case.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn'ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says:"In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption."It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] [76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: sysfs: Prevent div by zeroPrevent a division by 0 when monitoring is not enabled.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix when get product name maybe null pointerDue to incorrect dev->product reporting by certain devices, nullpointer dereferences occur when dev->product is empty, leading topotential system crashes.This issue was found on EXCELSIOR DL37-D05 device withLoongson-LS3A6000-7A2000-DL37 motherboard.Kernel logs:[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci[ 56.671638] usb 4-3: string descriptor 0 read error: -22[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07[ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0[ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80[ 56.697732] Oops[#1]:[ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015[ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024[ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0[ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000[ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000[ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005[ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000[ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028[ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000[ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000[ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom][ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120[ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)[ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)[ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)[ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)[ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)[ 56.697835] BADV: 0000000000000000[ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)[ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit[ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)[ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000[ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000[ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0[ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c[ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440[ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0[ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c[ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000[ 56.697931] 90000001000bb8d0 ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: grgpio: Add NULL check in grgpio_probedevm_kasprintf() can return a NULL pointer on failure,but thisreturned value in grgpio_probe is not checked.Add NULL check in grgpio_probe, to handle kernel NULLpointer dereference error.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: control: Avoid WARN() for symlink errorsUsing WARN() for showing the error of symlink creations don't givemore information than telling that something goes wrong, since theusual code path is a lregister callback from each control elementcreation. More badly, the use of WARN() rather confuses fuzzer as ifit were serious issues.This patch downgrades the warning messages to use the normal dev_err()instead of WARN(). For making it clearer, add the function name tothe prefix, too.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lapb: increase LAPB_HEADER_LENIt is unclear if net/lapb code is supposed to be ready for 8021q.We can at least avoid crashes like the following :skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, prevent potential error pointer dereferenceThe dr_domain_add_vport_cap() function generally returns NULL on errorbut sometimes we want it to return ERR_PTR(-EBUSY) so the caller canretry. The problem here is that "ret" can be either -EBUSY or -ENOMEMand if it's and -ENOMEM then the error pointer is propogated back andeventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_progSyzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULLThe fix makes sure the perf_event_detach_bpf_prog checks prog_arrayis valid before it tries to remove the bpf program from it.[1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: hdmi: Avoid hang with debug registers when suspendedTrying to read /sys/kernel/debug/dri/1/hdmi1_regswhen the hdmi is disconnected results in a fatal system hang.This is due to the pm suspend code disabling the dvp clock.That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG,which results in accesses hanging AXI bus.Protect against this.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.'''sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock'''This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/xen: fix release of IRQKernel logs indicate an IRQ was double-freed.Pass correct device ID during IRQ release.[Dominique: remove confusing variable reset to 0]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.cAdd error pointer checks after calling otx2_mbox_get_rsp().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if iowq is killed before queuingtask work can be executed after the task has gone through io_uringtermination, whether it's the final task_work run or the fallback path.In this case, task work will find ->io_wq being already killed andnull'ed, which is a problem if it then tries to forward the request toio_queue_iowq(). Make io_queue_iowq() fail requests in this case.Note that it also checks PF_KTHREAD, because the user can first closea DEFER_TASKRUN ring and shortly after kill the task, in which case->iowq check would race.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ionic: Fix netdev notifier unregister on failureIf register_netdev() fails, then the driver leaks the netdev notifier.Fix this by calling ionic_lif_unregister() on register_netdev()failure. This will also call ionic_lif_unregister_phc() if it hasalready been registered.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: prevent bad user input in nsim_dev_health_break_write()If either a zero count or a large one is provided, kernel can crash.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix TSO DMA API usage causing oopsCommit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmapfor non-paged SKB data") moved the assignment of tx_skbuff_dma[]'smembers to be later in stmmac_tso_xmit().The buf (dma cookie) and len stored in this structure are passed todma_unmap_single() by stmmac_tx_clean(). The DMA API requires thatthe dma cookie passed to dma_unmap_single() is the same as the valuereturned from dma_map_single(). However, by moving the assignmentlater, this is not the case when priv->dma_cap.addr64 > 32 as "des"is offset by proto_hdr_len.This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failedand with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]Fix this by maintaining "des" as the original DMA cookie, and usetso_des to pass the offset DMA cookie to stmmac_tso_allocator().Full details of the crashes can be found at:https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Several fixes to bpf_msg_pop_dataSeveral fixes to bpf_msg_pop_data,1. In sk_msg_shift_left, we should put_page2. if (len == 0), return early is better3. pop the entire sk_msg (last == msg->sg.size) should be supported4. Fix for the value of variable "a"5. In sk_msg_shift_left, after shifting, i has already pointed to the nextelement. Addtional sk_msg_iter_var_next may result in BUG.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix cpu stuck caused by printings during resetDuring reset, cmd to destroy resources such as qp, cq, and mr may fail,and error logs will be printed. When a large number of resources aredestroyed, there will be lots of printings, and it may lead to a cpustuck.Delete some unnecessary printings and replace other printing functionsin these paths with the ratelimited version.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devicesWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.cAdding error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()Fix an unwind issue in mlx5vf_add_migration_pages().If a set of pages is allocated but fails to be added to the SG table,they need to be freed to prevent a memory leak.Any pages successfully added to the SG table will be freed as part ofmlx5vf_free_data_buffer().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add a sanity check for btrfs root in btrfs_search_slot()Syzbot reports a null-ptr-deref in btrfs_search_slot().The reproducer is using rescue=ibadroots, and the extent tree root iscorrupted thus the extent tree is NULL.When scrub tries to search the extent tree to gather the needed extentinfo, btrfs_search_slot() doesn't check if the target root is NULL ornot, resulting the null-ptr-deref.Add sanity check for btrfs root before using it in btrfs_search_slot().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: imx8m: Probe the SoC driver as platform driverWith driver_async_probe=* on kernel command line, the following trace isproduced because on i.MX8M Plus hardware because the soc-imx8m.c drivercalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clockdriver is not yet probed. This was not detected during regular testingwithout driver_async_probe.Convert the SoC code to platform driver and instantiate a platform devicein its current device_initcall() to probe the platform driver. Rework.soc_revision callback to always return valid error code and return SoCrevision via parameter. This way, if anything in the .soc_revision callbackreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will getretried later."------------[ cut here ]------------WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : imx8mm_soc_revision+0xdc/0x180lr : imx8mm_soc_revision+0xd0/0x180sp : ffff8000821fbcc0x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfbx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95cx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfbCall trace: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---SoC: i.MX8MP revision 1.1"
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix for a potential deadlockThis fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);Fix this by temporarily releasing the reset_mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: imx6: Fix suspend/resume support on i.MX6QDLThe suspend/resume functionality is currently broken on the i.MX6QDLplatform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdfThis patch addresses the issue by sharing most of the suspend/resumesequences used by other i.MX devices, while avoiding modifications tocritical registers that disrupt the PCIe functionality. It targets thesame problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995Unlike the downstream commit, this patch also resets the connected PCIedevice if possible. Without this reset, certain drivers, such as ath10kor iwlwifi, will crash on resume. The device reset is also done by thedriver on other i.MX platforms, making this patch consistent withexisting practices.Upon resuming, the kernel will hang and display an error. Here's anexample of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944Without this patch, suspend/resume will fail on i.MX6QDL devices if aPCIe device is connected.[kwilczynski: commit log, added tag for stable releases]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_threadsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]If dvb->mux is not initialized successfully by vidtv_mux_init() in thevidtv_start_streaming(), it will trigger null pointer dereference about muxin vidtv_mux_stop_thread().Adjust the timing of streaming initialization and check it beforestopping it.[1]KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM workerAfter commit746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720... [ ] The intent of the verifcation done in check_flush_depedency is to ensureforward progress during memory reclaim, by flagging cases when either amemory reclaim process, or a memory reclaim work item is flushed from acontext not marked as memory reclaim safe.This is correct when flushing, but when called from thecancel(_delayed)_work_sync() paths it is a false positive because work iseither already running, or will not be running at all. Thereforecancelling it is safe and we can relax the warning criteria by letting thehelper know of the calling context.References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap lockingIf a device uses MCP23xxx IO expander to receive IRQs, the followingbug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...We observed the problem while experimenting with a touchscreen driver whichused MCP23017 IO expander (I2C).The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection fromconcurrent accesses, which is the default for regmaps without .fast_io,.disable_locking, etc.mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latterlocks the mutex.However, __setup_irq() locks desc->lock spinlock before calling thesefunctions. As a result, the system tries to lock the mutex whole holdingthe spinlock.It seems, the internal regmap locks are not needed in this driver at all.mcp->lock seems to protect the regmap from concurrent accesses already,except, probably, in mcp_pinconf_get/set.mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called underchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takesmcp->lock and enables regmap caching, so that the potentially slow I2Caccesses are deferred until chip_bus_unlock().The accesses to the regmap from mcp23s08_probe_one() do not need additionallocking.In all remaining places where the regmap is accessed, exceptmcp_pinconf_get/set(), the driver already takes mcp->lock.This patch adds locking in mcp_pinconf_get/set() and disables internallocking in the regmap config. Among other things, it fixes the sleepingin atomic context described above.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed. Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: flush delalloc workers queue before stopping cleaner kthread during unmountDuring the unmount path, at close_ctree(), we first stop the cleanerkthread, using kthread_stop() which frees the associated task_struct, andthen stop and destroy all the work queues. However after we stopped thecleaner we may still have a worker from the delalloc_workers queue runninginode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),which in turn tries to wake up the cleaner kthread - which was alreadydestroyed before, resulting in a use-after-free on the task_struct.Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XSK operations on the existence of queuesThis patch predicates the enabling and disabling of XSK pools on theexistence of queues. As it stands, if the interface is down, disablingor enabling XSK pools would result in a crash, as the RX queue pointerwould be NULL. XSK pool registration will occur as part of the nextinterface up.Similarly, xsk_wakeup needs be guarded against queues disappearingwhile the function is executing, so a check against theGVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with thedisabling of the bit and the synchronize_net() in gve_turndown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix accessing invalid dip_ctx during destroying QPIf it fails to modify QP to RTR, dip_ctx will not be attached. Andduring detroying QP, the invalid dip_ctx pointer will be accessed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-blk: don't keep queue frozen during system suspendCommit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues beforedeleting vqs.") replaces queue quiesce with queue freeze in virtio-blk'sPM callbacks. And the motivation is to drain inflight IOs before suspending.block layer's queue freeze looks very handy, but it is also easy to causedeadlock, such as, any attempt to call into bio_queue_enter() may run intodeadlock if the queue is frozen in current context. There are all kindsof ->suspend() called in suspend context, so keeping queue frozen in thewhole suspend context isn't one good idea. And Marek reported lockdepwarning[1] caused by virtio-blk's freeze queue in virtblk_freeze().[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/Given the motivation is to drain in-flight IOs, it can be done by callingfreeze & unfreeze, meantime restore to previous behavior by keeping queuequiesced during suspend.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Remove dangling pointersWhen an async control is written, we copy a pointer to the file handlethat started the operation. That pointer will be used when the device isdone. Which could be anytime in the future.If the user closes that file descriptor, its structure will be freed,and there will be one dangling pointer per pending async control, thatthe driver will try to use.Clean all the dangling pointers during release().To avoid adding a performance penalty in the most common case (no asyncoperation), a counter has been introduced with some logic to make surethat it is properly handled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()The ub913 and ub953 drivers call fwnode_handle_put(priv->sd.fwnode) aspart of their remove process, and if the driver is removed multipletimes, eventually leads to put "overflow", possibly causing memorycorruption or crash.The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media:i2c: ds90ub9x3: Fix sub-device matching"), which changed the coderelated to the sd.fwnode, but missed removing these fwnode_handle_put()calls.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: intel/ipu6: remove cpu latency qos request on errorFix cpu latency qos list corruption like below. It happens whenwe do not remove cpu latency request on error path and freecorresponding memory.[ 30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).[ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0[ 30.634640] l7 kernel: Call Trace:[ 30.634650] l7 kernel: [ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0[ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6[ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0[ 30.634690] l7 kernel: ? report_bug+0xff/0x140[ 30.634702] l7 kernel: ? handle_bug+0x58/0x90[ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70[ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20[ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0[ 30.634742] l7 kernel: plist_add+0xdd/0x140[ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0[ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0[ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() updateinbound map address") set_bar() was modified to support dynamicallychanging the backing physical address of a BAR that was already configured.This means that set_bar() can be called twice, without ever callingclear_bar() (as calling clear_bar() would clear the BAR's PCI addressassigned by the host).This can only be done if the new BAR size/flags does not differ from theexisting BAR configuration. Add these missing checks.If we allow set_bar() to set e.g. a new BAR size that differs from theexisting BAR size, the new address translation range will be smaller thanthe BAR size already determined by the host, which would mean that a readpast the new BAR size would pass the iATU untranslated, which could allowthe host to read memory not belonging to the new struct pci_epf_bar.While at it, add comments which clarifies the support for dynamicallychanging the physical address of a BAR. (Which was also missing.)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: socinfo: Avoid out of bounds read of serial numberOn MSM8916 devices, the serial number exposed in sysfs is constant and doesnot change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does nothave support for the serial_num field in the socinfo struct. There is anexisting check to avoid exposing the serial number in that case, but it'snot correct: When checking the item_size returned by SMEM, we need to makesure the *end* of the serial_num is within bounds, instead of comparingwith the *start* offset. The serial_number currently exposed on MSM8916devices is just an out of bounds read of whatever comes after the socinfostruct in SMEM.Fix this by changing offsetof() to offsetofend(), so that the size of thefield is also taken into account.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=yWith vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trustedkeys can crash during en- and decryption of the blob encryption key viathe DCP crypto driver. This is caused by improperly using sg_init_one()with vmalloc'd stack buffers (plain_key_blob).Fix this by always using kmalloc() for buffers we give to the DCP cryptodriver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: int3472: Check for adev == NULLNot all devices have an ACPI companion fwnode, so adev might be NULL. Thiscan e.g. (theoretically) happen when a user manually binds one ofthe int3472 drivers to another i2c/platform device through sysfs.Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix for out-of bound access errorSelfgen stats are placed in a buffer using print_array_to_buf_index() function.Array length parameter passed to the function is too big, resulting in possibleout-of bound memory error.Decreasing buffer size by one fixes faulty upper bound of passed array.Discovered in coverity scan, CID 1600742 and CID 1600758
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvkm: correctly calculate the available space of the GSP cmdq bufferr535_gsp_cmdq_push() waits for the available page in the GSP cmdqbuffer when handling a large RPC request. When it sees at least oneavailable page in the cmdq, it quits the waiting with the amount offree buffer pages in the queue.Unfortunately, it always takes the [write pointer, buf_size) asavailable buffer pages before rolling back and wrongly calculates thesize of the data should be copied. Thus, it can overwrite the RPCrequest that GSP is currently reading, which causes GSP hang dueto corrupted RPC request:[ 549.209389] ------------[ cut here ]------------[ 549.214010] WARNING: CPU: 8 PID: 6314 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:116 r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.225678] Modules linked in: nvkm(E+) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) mlx5_ib(E) amd64_edac(E) edac_mce_amd(E) kvm_amd(E) ib_uverbs(E) kvm(E) ib_core(E) acpi_ipmi(E) ipmi_si(E) mxm_wmi(E) ipmi_devintf(E) rapl(E) i2c_piix4(E) wmi_bmof(E) joydev(E) ptdma(E) acpi_cpufreq(E) k10temp(E) pcspkr(E) ipmi_msghandler(E) xfs(E) libcrc32c(E) ast(E) i2c_algo_bit(E) crct10dif_pclmul(E) drm_shmem_helper(E) nvme_tcp(E) crc32_pclmul(E) ahci(E) drm_kms_helper(E) libahci(E) nvme_fabrics(E) crc32c_intel(E) nvme(E) cdc_ether(E) mlx5_core(E) nvme_core(E) usbnet(E) drm(E) libata(E) ccp(E) ghash_clmulni_intel(E) mii(E) t10_pi(E) mlxfw(E) sp5100_tco(E) psample(E) pci_hyperv_intf(E) wmi(E) dm_multipath(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) be2iscsi(E) bnx2i(E) cnic(E) uio(E) cxgb4i(E) cxgb4(E) tls(E) libcxgbi(E) libcxgb(E) qla4xxx(E)[ 549.225752] iscsi_boot_sysfs(E) iscsi_tcp(E) libiscsi_tcp(E) libiscsi(E) scsi_transport_iscsi(E) fuse(E) [last unloaded: gsp_log(E)][ 549.326293] CPU: 8 PID: 6314 Comm: insmod Tainted: G E 6.9.0-rc6+ #1[ 549.334039] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022[ 549.341781] RIP: 0010:r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.347343] Code: 08 00 00 89 da c1 e2 0c 48 8d ac 11 00 10 00 00 48 8b 0c 24 48 85 c9 74 1f c1 e0 0c 4c 8d 6d 30 83 e8 30 89 01 e9 68 ff ff ff <0f> 0b 49 c7 c5 92 ff ff ff e9 5a ff ff ff ba ff ff ff ff be c0 0c[ 549.366090] RSP: 0018:ffffacbccaaeb7d0 EFLAGS: 00010246[ 549.371315] RAX: 0000000000000000 RBX: 0000000000000012 RCX: 0000000000923e28[ 549.378451] RDX: 0000000000000000 RSI: 0000000055555554 RDI: ffffacbccaaeb730[ 549.385590] RBP: 0000000000000001 R08: ffff8bd14d235f70 R09: ffff8bd14d235f70[ 549.392721] R10: 0000000000000002 R11: ffff8bd14d233864 R12: 0000000000000020[ 549.399854] R13: ffffacbccaaeb818 R14: 0000000000000020 R15: ffff8bb298c67000[ 549.406988] FS: 00007f5179244740(0000) GS:ffff8bd14d200000(0000) knlGS:0000000000000000[ 549.415076] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 549.420829] CR2: 00007fa844000010 CR3: 00000001567dc005 CR4: 0000000000770ef0[ 549.427963] PKRU: 55555554[ 549.430672] Call Trace:[ 549.433126] [ 549.435233] ? __warn+0x7f/0x130[ 549.438473] ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.443426] ? report_bug+0x18a/0x1a0[ 549.447098] ? handle_bug+0x3c/0x70[ 549.450589] ? exc_invalid_op+0x14/0x70[ 549.454430] ? asm_exc_invalid_op+0x16/0x20[ 549.458619] ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm][ 549.463565] r535_gsp_msg_recv+0x46/0x230 [nvkm][ 549.468257] r535_gsp_rpc_push+0x106/0x160 [nvkm][ 549.473033] r535_gsp_rpc_rm_ctrl_push+0x40/0x130 [nvkm][ 549.478422] nvidia_grid_init_vgpu_types+0xbc/0xe0 [nvkm][ 549.483899] nvidia_grid_init+0xb1/0xd0 [nvkm][ 549.488420] ? srso_alias_return_thunk+0x5/0xfbef5[ 549.493213] nvkm_device_pci_probe+0x305/0x420 [nvkm][ 549.498338] local_pci_probe+0x46/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvkm/gsp: correctly advance the read pointer of GSP message queueA GSP event message consists three parts: message header, RPC header,message body. GSP calculates the number of pages to write from thetotal size of a GSP message. This behavior can be observed from themovement of the write pointer.However, nvkm takes only the size of RPC header and message body asthe message size when advancing the read pointer. When handling atwo-page GSP message in the non rollback case, It wrongly takes themessage body of the previous message as the message header of the nextmessage. As the "message length" tends to be zero, in the calculation ofsize needs to be copied (0 - size of (message header)), the size needs tobe copied will be "0xffffffxx". It also triggers a kernel panic due to aNULL pointer error.[ 547.614102] msg: 00000f90: ff ff ff ff ff ff ff ff 40 d7 18 fb 8b 00 00 00 ........@.......[ 547.622533] msg: 00000fa0: 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00 ................[ 547.630965] msg: 00000fb0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................[ 547.639397] msg: 00000fc0: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................[ 547.647832] nvkm 0000:c1:00.0: gsp: peek msg rpc fn:0 len:0x0/0xffffffffffffffe0[ 547.655225] nvkm 0000:c1:00.0: gsp: get msg rpc fn:0 len:0x0/0xffffffffffffffe0[ 547.662532] BUG: kernel NULL pointer dereference, address: 0000000000000020[ 547.669485] #PF: supervisor read access in kernel mode[ 547.674624] #PF: error_code(0x0000) - not-present page[ 547.679755] PGD 0 P4D 0[ 547.682294] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 547.686643] CPU: 22 PID: 322 Comm: kworker/22:1 Tainted: G E 6.9.0-rc6+ #1[ 547.694893] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022[ 547.702626] Workqueue: events r535_gsp_msgq_work [nvkm][ 547.707921] RIP: 0010:r535_gsp_msg_recv+0x87/0x230 [nvkm][ 547.713375] Code: 00 8b 70 08 48 89 e1 31 d2 4c 89 f7 e8 12 f5 ff ff 48 89 c5 48 85 c0 0f 84 cf 00 00 00 48 81 fd 00 f0 ff ff 0f 87 c4 00 00 00 <8b> 55 10 41 8b 46 30 85 d2 0f 85 f6 00 00 00 83 f8 04 76 10 ba 05[ 547.732119] RSP: 0018:ffffabe440f87e10 EFLAGS: 00010203[ 547.737335] RAX: 0000000000000010 RBX: 0000000000000008 RCX: 000000000000003f[ 547.744461] RDX: 0000000000000000 RSI: ffffabe4480a8030 RDI: 0000000000000010[ 547.751585] RBP: 0000000000000010 R08: 0000000000000000 R09: ffffabe440f87bb0[ 547.758707] R10: ffffabe440f87dc8 R11: 0000000000000010 R12: 0000000000000000[ 547.765834] R13: 0000000000000000 R14: ffff9351df1e5000 R15: 0000000000000000[ 547.772958] FS: 0000000000000000(0000) GS:ffff93708eb00000(0000) knlGS:0000000000000000[ 547.781035] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 547.786771] CR2: 0000000000000020 CR3: 00000003cc220002 CR4: 0000000000770ef0[ 547.793896] PKRU: 55555554[ 547.796600] Call Trace:[ 547.799046] [ 547.801152] ? __die+0x20/0x70[ 547.804211] ? page_fault_oops+0x75/0x170[ 547.808221] ? print_hex_dump+0x100/0x160[ 547.812226] ? exc_page_fault+0x64/0x150[ 547.816152] ? asm_exc_page_fault+0x22/0x30[ 547.820341] ? r535_gsp_msg_recv+0x87/0x230 [nvkm][ 547.825184] r535_gsp_msgq_work+0x42/0x50 [nvkm][ 547.829845] process_one_work+0x196/0x3d0[ 547.833861] worker_thread+0x2fc/0x410[ 547.837613] ? __pfx_worker_thread+0x10/0x10[ 547.841885] kthread+0xdf/0x110[ 547.845031] ? __pfx_kthread+0x10/0x10[ 547.848775] ret_from_fork+0x30/0x50[ 547.852354] ? __pfx_kthread+0x10/0x10[ 547.856097] ret_from_fork_asm+0x1a/0x30[ 547.860019] [ 547.862208] Modules linked in: nvkm(E) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) mlx5_ib(E) edac_mce_amd(E) kvm_amd---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: winwing: Add NULL check in winwing_init_led()devm_kasprintf() can return a NULL pointer on failure,but thisreturned value in winwing_init_led() is not checked.Add NULL check in winwing_init_led(), to handle kernel NULLpointer dereference error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: gcc-sm6350: Add missing parent_map for two clocksIf a clk_rcg2 has a parent, it should also have parent_map defined,otherwise we'll get a NULL pointer dereference when calling clk_set_ratelike the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14cAdd the parent_map property for two clocks where it's missing and alsoun-inline the parent_data as well to keep the matching parent_map andparent_data together.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minorsmisc_minor_alloc was allocating id using ida for minor only in case ofMISC_DYNAMIC_MINOR but misc_minor_free was always freeing idsusing ida_free causing a mismatch and following warn:> > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f> > ida_free called for id=127 which is not allocated.> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<...> > [<60941eb4>] ida_free+0x3e0/0x41f> > [<605ac993>] misc_minor_free+0x3e/0xbc> > [<605acb82>] misc_deregister+0x171/0x1b3misc_minor_alloc is changed to allocate id from ida for all minorsfalling in the range of dynamic/ misc dynamic minors
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix crash during unbind if gpio unit is in useWe used the wrong device for the device managed functions. We used theusb device, when we should be using the interface device.If we unbind the driver from the usb interface, the cleanup functionsare never called. In our case, the IRQ is never disabled.If an IRQ is triggered, it will try to access memory sections that arealready free, causing an OOPS.We cannot use the function devm_request_threaded_irq here. The devm_*clean functions may be called after the main structure is released byuvc_delete.Luckily this bug has small impact, as it is only affected by deviceswith gpio units and the user has to unbind the device, a disconnect willnot trigger this error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: dispcc-sm6350: Add missing parent_map for a clockIf a clk_rcg2 has a parent, it should also have parent_map defined,otherwise we'll get a NULL pointer dereference when calling clk_set_ratelike the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14cAdd the parent_map property for the clock where it's missing and alsoun-inline the parent_data as well to keep the matching parent_map andparent_data together.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mmp2: call pm_genpd_init() only after genpd.name is setSetting the genpd's struct device's name with dev_set_name() ishappening within pm_genpd_init(). If it remains NULL, things can blow uplater, such as when crafting the devfs hierarchy for the power domain: Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read ... Call trace: strlen from start_creating+0x90/0x138 start_creating from debugfs_create_dir+0x20/0x178 debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144 genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90 genpd_debug_init from do_one_initcall+0x5c/0x244 do_one_initcall from kernel_init_freeable+0x19c/0x1f4 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x28Bisecting tracks this crash back to commit 899f44531fe6 ("pmdomain: core:Add GENPD_FLAG_DEV_NAME_FW flag"), which exchanges use of genpd->namewith dev_name(&genpd->dev) in genpd_debug_add.part().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: nuvoton: Fix an error check in npcm_video_ece_init()When function of_find_device_by_node() fails, it returns NULL instead ofan error code. So the corresponding error check logic should be modifiedto check whether the return value is NULL and set the error code to bereturned as -ENODEV.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()Explicitly verify the target vCPU is fully online _prior_ to clamping theindex in kvm_get_vcpu(). If the index is "bad", the nospec clamping willgenerate '0', i.e. KVM will return vCPU0 instead of NULL.In practice, the bug is unlikely to cause problems, as it will only comeinto play if userspace or the guest is buggy or misbehaving, e.g. KVM maysend interrupts to vCPU0 instead of dropping them on the floor.However, returning vCPU0 when it shouldn't exist per online_vcpus isproblematic now that KVM uses an xarray for the vCPUs array, as KVM needsto insert into the xarray before publishing the vCPU to userspace (seecommit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),i.e. before vCPU creation is guaranteed to succeed.As a result, incorrectly providing access to vCPU0 will trigger ause-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()bails out of vCPU creation due to an error and frees vCPU0. Commitafb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, butin doing so introduced an unsolvable teardown conundrum. Preventingaccesses to vCPU0 before it's fully online will allow reverting commitafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitqcompletion variable initialization") introduced a write barrier in probefunction to store global '__scm' variable. We all known barriers arepaired (see memory-barriers.txt: "Note that write barriers shouldnormally be paired with read or address-dependency barriers"), thereforeaccessing it from concurrent contexts requires read barrier. Previouscommit added such barrier in qcom_scm_is_available(), so let's use thatdirectly.Lack of this read barrier can result in fetching stale '__scm' variablevalue, NULL, and dereferencing it.Note that barrier in qcom_scm_is_available() satisfies here the controldependency.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Stop active perfmon if it is being destroyedIf the active performance monitor (`v3d->active_perfmon`) is beingdestroyed, stop it first. Currently, the active perfmon is notstopped during destruction, leaving the `v3d->active_perfmon` pointerstale. This can lead to undefined behavior and instability.This patch ensures that the active perfmon is stopped before beingdestroyed, aligning with the behavior introduced in commit7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double accounting race when btrfs_run_delalloc_range() failed[BUG]When running btrfs with block size (4K) smaller than page size (64K,aarch64), there is a very high chance to crash the kernel atgeneric/750, with the following messages:(before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b[CAUSE]The above warning is triggered immediately after the delalloc rangefailure, this happens in the following sequence:- Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size)- Enter extent_writepage() for page 1536K- Enter run_delalloc_nocow() with locke---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/fbdev-dma: Add shadow buffering for deferred I/ODMA areas are not necessarily backed by struct page, so we cannotrely on it for deferred I/O. Allocate a shadow buffer for driversthat require deferred I/O and use it as framebuffer memory.Fixes driver errors about being "Unable to handle kernel NULL pointerdereference at virtual address" or "Unable to handle kernel pagingrequest at virtual address".The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initialallocation, which creates the DMA-backed buffer object, and a tailthat sets up the fbdev data structures. There is a tail function fordirect memory mappings and a tail function for deferred I/O withthe shadow buffer.It is no longer possible to use deferred I/O without shadow buffer.It can be re-added if there exists a reliably test for usable structpage in the allocated DMA-backed buffer object.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free"), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free'd memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix RCU stall while reaping monitor destination ringWhile processing the monitor destination ring, MSDUs are reaped from thelink descriptor based on the corresponding buf_id.However, sometimes the driver cannot obtain a valid buffer correspondingto the buf_id received from the hardware. This causes an infinite loopin the destination processing, resulting in a kernel crash.kernel log:ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedFix this by skipping the problematic buf_id and reaping the next entry,replacing the break with the next MSDU processing.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxslt1 > 0-0 (version in image is 1.1.34-150400.3.6.1).
-
Description: Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.95.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.probe_interval' isused.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: udp_port: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled itWakeup for IRQ1 should be disabled only in cases where i8042 hadactually enabled it, otherwise "wake_depth" for this IRQ will try todrop below zero and there will be an unpleasant WARN() logged:kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bugkernel: ------------[ cut here ]------------kernel: Unbalanced IRQ 1 wake disablekernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_opswhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and.poweroff handlers. i8042_pm_suspend(), however, is only set asthe .suspend handler.Fix the issue by call PMC suspend handler only from the same set ofdev_pm_ops handlers as i8042_pm_suspend(), which currently means justthe .suspend handler.To reproduce this issue try hibernating (S4) the machine after a fresh bootwithout putting it into s2idle first.[ij: edited the commit message.]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix the maximum cell name lengthThe kafs filesystem limits the maximum length of a cell to 256 bytes, but aproblem occurs if someone actually does that: kafs tries to create adirectory under /proc/net/afs/ with the name of the cell, but that failswith a warning: WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405because procfs limits the maximum filename length to 255.However, the DNS limits the maximum lookup length and, by extension, themaximum cell name, to 255 less two (length count and trailing NUL).Fix this by limiting the maximum acceptable cellname length to 253. Thisalso allows us to be sure we can create the "/afs/.| /" mountpoint too.Further, split the YFS VL record cell name maximum to be the 256 allowed bythe protocol and ignore the record retrieved by YFSVL.GetCellName if itexceeds 253.
|
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is sent on HIP08 devicesCurrently, HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL. But the tx process would still try to set hardware timestamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge][ 128.292938] sp : ffff800059b93140[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001[ 128.315969] x23: 0000000000000000 x22: 0000000000000194[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080[ 128.390626] Call trace:[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3][ 128.405468] xmit_one.constprop.0+0xc4/0x200[ 128.410600] dev_hard_start_xmit+0x54/0xf0[ 128.415556] sch_direct_xmit+0xe8/0x634[ 128.420246] __dev_queue_xmit+0x224/0xc70[ 128.425101] dev_queue_xmit+0x1c/0x40[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch][ 128.435409] do_output+0x60/0x17c [openvswitch][ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch][ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch][ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch][ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch][ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch][ 128.471460] xmit_one.constprop.0+0xc4/0x200[ 128.476561] dev_hard_start_xmit+0x54/0xf0[ 128.481489] __dev_queue_xmit+0x968/0xc70[ 128.486330] dev_queue_xmit+0x1c/0x40[ 128.490856] ip_finish_output2+0x250/0x570[ 128.495810] __ip_finish_output+0x170/0x1e0[ 128.500832] ip_finish_output+0x3c/0xf0[ 128.505504] ip_output+0xbc/0x160[ 128.509654] ip_send_skb+0x58/0xd4[ 128.513892] udp_send_skb+0x12c/0x354[ 128.518387] udp_sendmsg+0x7a8/0x9c0[ 128.522793] inet_sendmsg+0x4c/0x8c[ 128.527116] __sock_sendmsg+0x48/0x80[ 128.531609] __sys_sendto+0x124/0x164[ 128.536099] __arm64_sys_sendto+0x30/0x5c[ 128.540935] invoke_syscall+0x50/0x130[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124[ 128.551205] do_el0_svc+0x34/0xdc[ 128.555347] el0_svc+0x20/0x30[ 128.559227] el0_sync_handler+0xb8/0xc0[ 128.563883] el0_sync+0x160/0x180
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid NULL pointer dereference if no valid extent tree[BUG]Syzbot reported a crash with the following call trace: BTRFS info (device loop0): scrub: started on devid 1 BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs] scrub_simple_mirror+0x175/0x260 [btrfs] scrub_stripe+0x5d4/0x6c0 [btrfs] scrub_chunk+0xbb/0x170 [btrfs] scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs] btrfs_scrub_dev+0x240/0x600 [btrfs] btrfs_ioctl+0x1dc8/0x2fa0 [btrfs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE]The reproducer is using a corrupted image where extent tree root iscorrupted, thus forcing to use "rescue=all,ro" mount option to mount theimage.Then it triggered a scrub, but since scrub relies on extent tree to findwhere the data/metadata extents are, scrub_find_fill_first_stripe()relies on an non-empty extent root.But unfortunately scrub_find_fill_first_stripe() doesn't really expectan NULL pointer for extent root, it use extent_root to grab fs_info andtriggered a NULL pointer dereference.[FIX]Add an extra check for a valid extent root at the beginning ofscrub_find_fill_first_stripe().The new error path is introduced by 42437a6386ff ("btrfs: introducemount option rescue=ignorebadroots"), but that's pretty old, and latercommit b979547513ff ("btrfs: scrub: introduce helper to find and fillsector info for a scrub_stripe") changed how we do scrub.So for kernels older than 6.6, the fix will need manual backport.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix variable not being completed when function returnsWhen cmd_alloc_index(), fails cmd_work_handler() needsto complete ent->slotted before returning early.Otherwise the task which issued the command may hang: mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: dwmac-tegra: Read iommu stream id from device treeNvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to bewritten to the MGBE_WRAP_AXI_ASID0_CTRL register.The current driver is hard coded to use MGBE0's SID for all controllers.This causes softirq time outs and kernel panics when using controllersother than MGBE0.Example dmesg errors when an ethernet cable is connected to MGBE1:[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx[ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms[ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.[ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0[ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)[ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features[ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported[ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock[ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode[ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx[ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:[ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337[ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)[ 181.921878] Sending NMI from CPU 4 to CPUs 7:[ 181.921886] NMI backtrace for cpu 7[ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6[ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024[ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 181.922847] pc : handle_softirqs+0x98/0x368[ 181.922978] lr : __do_softirq+0x18/0x20[ 181.923095] sp : ffff80008003bf50[ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000[ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0[ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70[ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000[ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000[ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d[ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160[ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74[ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1[ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000[ 181.967591] Call trace:[ 181.970043] handle_softirqs+0x98/0x368 (P)[ 181.974240] __do_softirq+0x18/0x20[ 181.977743] ____do_softirq+0x14/0x28[ 181.981415] call_on_irq_stack+0x24/0x30[ 181.985180] do_softirq_own_stack+0x20/0x30[ 181.989379] __irq_exit_rcu+0x114/0x140[ 181.993142] irq_exit_rcu+0x14/0x28[ 181.996816] el1_interrupt+0x44/0xb8[ 182.000316] el1h_64_irq_handler+0x14/0x20[ 182.004343] el1h_64_irq+0x80/0x88[ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)[ 182.012305] cpuidle_enter+0x3c/0x58[ 182.015980] cpuidle_idle_call+0x128/0x1c0[ 182.020005] do_idle+0xe0/0xf0[ 182.023155] cpu_startup_entry+0x3c/0x48[ 182.026917] secondary_start_kernel+0xdc/0x120[ 182.031379] __secondary_switched+0x74/0x78[ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.[ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):[ 212.992758] Sending NMI from CPU 0 to CPUs 7:[ 212.998539] NMI backtrace for cpu 7[ 213.004304] CPU: 7 UID: 0 PI---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]Recent reports have shown how we sometimes call vsock_*_has_data()when a vsock socket has been de-assigned from a transport (see attachedlinks), but we shouldn't.Previous commits should have solved the real problems, but we may havemore in the future, so to avoid null-ptr-deref, we can return 0(no space, no data available) but with a warning.This way the code should continue to run in a nearly consistent stateand have a warning that allows us to debug future problems.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clear port select structure when fail to createClear the port select structure on error so no stale values left afterdefiners are destroyed. That's because the mlx5_lag_destroy_definers()always try to destroy all lag definers in the tt_map, so in the flowbelow lag definers get double-destroyed and cause kernel crash: mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 1 mlx5_lag_destroy_definers() <- definers[tt=0] gets destroyed mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 0 mlx5_lag_destroy_definers() <- definers[tt=0] gets double-destroyed Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core] mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core] mlx5_activate_lag+0x60c/0x6f8 [mlx5_core] mlx5_do_bond_work+0x284/0x5c8 [mlx5_core] process_one_work+0x170/0x3e0 worker_thread+0x2d8/0x3e0 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with errorThis patch addresses a race condition for an ODP MR that can result in aCQE with an error on the UMR QP.During the __mlx5_ib_dereg_mr() flow, the following sequence of callsoccurs:mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait()At this point, the lkey is freed from the hardware's perspective.However, concurrently, mlx5_ib_invalidate_range() might be triggered byanother task attempting to invalidate a range for the same freed lkey.This task will: - Acquire the umem_odp->umem_mutex lock. - Call mlx5r_umr_update_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].To resolve this race condition, the umem_odp->umem_mutex lock is now alsoacquired as part of the mlx5_revoke_mr() scope. Upon successful revoke,we set umem_odp->private which points to that MR to NULL, preventing anyfurther invalidation attempts on its lkey.[1] From dmesg: infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2 WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Call Trace: mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing/osnoise: Fix resetting of tracepointsIf a timerlat tracer is started with the osnoise option OSNOISE_WORKLOADdisabled, but then that option is enabled and timerlat is removed, thetracepoints that were enabled on timerlat registration do not getdisabled. If the option is disabled again and timelat is started, then ittriggers a warning in the tracepoint code due to registering thetracepoint again without ever disabling it.Do not use the same user space defined options to know to disable thetracepoints when timerlat is removed. Instead, set a global flag when itis enabled and use that flag to know to disable the events. ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer ~# echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo nop > /sys/kernel/tracing/current_tracer ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracerTriggers: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0 Modules linked in: CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tracepoint_add_func+0x3b6/0x3f0 Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001 R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008 FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0 Call Trace: ? __warn.cold+0xb7/0x14d ? tracepoint_add_func+0x3b6/0x3f0 ? report_bug+0xea/0x170 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? tracepoint_add_func+0x3b6/0x3f0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? __pfx_trace_sched_migrate_callback+0x10/0x10 tracepoint_probe_register+0x78/0xb0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 osnoise_workload_start+0x2b5/0x370 timerlat_tracer_init+0x76/0x1b0 tracing_set_tracer+0x244/0x400 tracing_set_trace_write+0xa0/0xe0 vfs_write+0xfc/0x570 ? do_sys_openat2+0x9c/0xe0 ksys_write+0x72/0xf0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix copy buffer page sizeFor non-registered buffer, fastrpc driver copies the buffer andpass it to the remote subsystem. There is a problem with currentimplementation of page size calculation which is not consideringthe offset in the calculation. This might lead to passing ofimproper and out-of-bounds page size which could result inmemory issue. Calculate page start and page end using the offsetadjusted address instead of absolute address.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix possible int overflows in nilfs_fiemap()Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its resultby being prepared to go through potentially maxblocks == INT_MAX blocks,the value in n may experience an overflow caused by left shift of blkbits.While it is extremely unlikely to occur, play it safe and cast right handexpression to wider type to mitigate the issue.Found by Linux Verification Center (linuxtesting.org) with static analysistool SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix memory leak in ceph_mds_auth_match()We now free the temporary target path substring allocation on everypossible branch, instead of omitting the default branch. In somecases, a memory leak occured, which could rapidly crash the system(depending on how many file accesses were attempted).This was detected in production because it caused a continuous memorygrowth, eventually triggering kernel OOM and completely hard-lockingthe kernel.Relevant kmemleak stacktrace: unreferenced object 0xffff888131e69900 (size 128): comm "git", pid 66104, jiffies 4295435999 hex dump (first 32 bytes): 76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65 volumes/containe 72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67 rs/gitea/gitea/g backtrace (crc 2f3bb450): [] __kmalloc_noprof+0x359/0x510 [] ceph_mds_check_access+0x5bf/0x14e0 [ceph] [] ceph_open+0x312/0xd80 [ceph] [] do_dentry_open+0x456/0x1120 [] vfs_open+0x79/0x360 [] path_openat+0x1de5/0x4390 [] do_filp_open+0x19c/0x3c0 [] do_sys_openat2+0x141/0x180 [] __x64_sys_open+0xe5/0x1a0 [] do_syscall_64+0xb7/0x210 [] entry_SYSCALL_64_after_hwframe+0x77/0x7fIt can be triggered by mouting a subdirectory of a CephFS filesystem,and then trying to access files on this subdirectory with an auth tokenusing a path-scoped capability: $ ceph auth get client.services [client.services] key = REDACTED caps mds = "allow rw fsname=cephfs path=/volumes/" caps mon = "allow r fsname=cephfs" caps osd = "allow rw tag cephfs data=cephfs" $ cat /proc/self/mounts services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=,ms_mode=prefer-crc,mount_timeout=300,acl,mon_addr=[REDACTED]:3300,recover_session=clean 0 0 $ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} && \ seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}[ idryomov: combine if statements, rename rc to path_matched and make it a bool, formatting ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: ipheth: fix DPE OoB readFix an out-of-bounds DPE read, limit the number of processed DPEs tothe amount that fits into the fixed-size NDP16 header.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: ipheth: use static NDP16 location in URBOriginal code allowed for the start of NDP16 to be anywhere within theURB based on the `wNdpIndex` value in NTH16. Only the start position ofNDP16 was checked, so it was possible for even the fixed-length partof NDP16 to extend past the end of URB, leading to an out-of-boundsread.On iOS devices, the NDP16 header always directly follows NTH16. Rely onand check for this specific format.This, along with NCM-specific minimal URB length check that alreadyexists, will ensure that the fixed-length part of NDP16 plus a setamount of DPEs fit within the URB.Note that this commit alone does not fully address the OoB read.The limit on the amount of DPEs needs to be enforced separately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: ipheth: fix possible overflow in DPE length checkOriginally, it was possible for the DPE length check to overflow ifwDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoBread.Move the wDatagramIndex term to the other side of the inequality.An existing condition ensures that wDatagramIndex < urb->actual_length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix class @block_class's subsystem refcount leakageblkcg_fill_root_iostats() iterates over @block_class's devices byclass_dev_iter_(init|next)(), but does not end iterating withclass_dev_iter_exit(), so causes the class's subsystem refcount leakage.Fix by ending the iterating with class_dev_iter_exit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ast: astdp: Fix timeout for enabling video signalThe ASTDP transmitter sometimes takes up to 1 second for enabling thevideo signal, while the timeout is only 200 msec. This results in akernel error message. Increase the timeout to 1 second. An exampleof the error message is shown below.[ 697.084433] ------------[ cut here ]------------[ 697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))[ 697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast][...][ 697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast][...][ 697.415283] Call Trace:[ 697.420727] [ 697.425908] ? show_trace_log_lvl+0x196/0x2c0[ 697.433304] ? show_trace_log_lvl+0x196/0x2c0[ 697.440693] ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470[ 697.450115] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.458059] ? __warn.cold+0xaf/0xca[ 697.464713] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.472633] ? report_bug+0x134/0x1d0[ 697.479544] ? handle_bug+0x58/0x90[ 697.486127] ? exc_invalid_op+0x13/0x40[ 697.492975] ? asm_exc_invalid_op+0x16/0x20[ 697.500224] ? preempt_count_sub+0x14/0xc0[ 697.507473] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.515377] ? ast_dp_set_enable+0x123/0x140 [ast][ 697.523227] drm_atomic_helper_commit_modeset_enables+0x30a/0x470[ 697.532388] drm_atomic_helper_commit_tail+0x58/0x90[ 697.540400] ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast][ 697.550009] commit_tail+0xfe/0x1d0[ 697.556547] drm_atomic_helper_commit+0x198/0x1c0This is a cosmetical problem. Enabling the video signal still workseven with the error message. The problem has always been present, butonly recent versions of the ast driver warn about missing the timeout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the return value of of_property_read_string_index()Somewhen between 6.10 and 6.11 the driver started to crash on myMacBookPro14,3. The property doesn't exist and 'tmp' remainsuninitialized, so we pass a random pointer to devm_kstrdup().The crash I am getting looks like this:BUG: unable to handle page fault for address: 00007f033c669379PF: supervisor read access in kernel modePF: error_code(0x0001) - permissions violationPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025Oops: Oops: 0001 [#1] SMP PTICPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024RIP: 0010:strlen+0x4/0x30Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 ccRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916aR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion failure when splitting ordered extent after transaction abortIf while we are doing a direct IO write a transaction abort happens, wemark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (doneat btrfs_destroy_ordered_extents()), and then after that if we enterbtrfs_split_ordered_extent() and the ordered extent has bytes left(meaning we have a bio that doesn't cover the whole ordered extent, seedetails at btrfs_extract_ordered_extent()), we will fail on the followingassertion at btrfs_split_ordered_extent(): ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS));because the BTRFS_ORDERED_IOERR flag is set and the definition ofBTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify thetype of write (regular, nocow, prealloc, compressed, direct IO, encoded).Fix this by returning an error from btrfs_extract_ordered_extent() if wefind the BTRFS_ORDERED_IOERR flag in the ordered extent. The error willbe the error that resulted in the transaction abort or -EIO if notransaction abort happened.This was recently reported by syzbot with the following trace: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [inline] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [inline] slab_alloc_node mm/slub.c:4148 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [inline] do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: extend RCU protection in ndisc_send_skb()ndisc_send_skb() can be called without RTNL or RCU held.Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()and avoid a potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: use RCU protection in ovs_vport_cmd_fill_info()ovs_vport_cmd_fill_info() can be called without RTNL or RCU.Use RCU protection and dev_net_rcu() to avoid potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: use RCU protection in ndisc_alloc_skb()ndisc_alloc_skb() can be called without RTNL or RCU being held.Add RCU protection to avoid possible UAF.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU protection in ip6_default_advmss()ip6_default_advmss() needs rcu protection to makesure the net structure it reads does not disappear.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: use RCU protection in __ip_rt_update_pmtu()__ip_rt_update_pmtu() must use RCU protection to makesure the net structure it reads does not disappear.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic contextThe following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0It is due to the fact that clocksource_verify_choose_cpus() is invoked withpreemption disabled. This function invokes get_random_u32() to obtainrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/orthe base_crng.lock spinlock in driver/char/random.c will be acquired duringthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannotbe acquired in atomic context.Fix this problem by using migrate_disable() to allow smp_processor_id() tobe reliably used without introducing atomic context. preempt_disable() isthen called after clocksource_verify_choose_cpus() but before theclocksource measurement is being run to avoid introducing unexpectedlatency.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: vmclock: Add .owner to vmclock_miscdev_fopsWithout the .owner field, the module can be unloaded while /dev/vmclock0is open, leading to an oops.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu: Fix potential memory leak in iopf_queue_remove_device()The iopf_queue_remove_device() helper removes a device from the per-iommuiopf queue when PRI is disabled on the device. It responds to alloutstanding iopf's with an IOMMU_PAGE_RESP_INVALID code and detaches thedevice from the queue.However, it fails to release the group structure that represents a groupof iopf's awaiting for a response after responding to the hardware. Thiscan cause a memory leak if iopf_queue_remove_device() is called withpending iopf's.Fix it by calling iopf_free_group() after the iopf group is responded.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched_ext: Fix incorrect autogroup migration detectionscx_move_task() is called from sched_move_task() and tells the BPF schedulerthat cgroup migration is being committed. sched_move_task() is used by bothcgroup and autogroup migrations and scx_move_task() tried to filter outautogroup migrations by testing the destination cgroup and PF_EXITING butthis is not enough. In fact, without explicitly tagging the thread which isdoing the cgroup migration, there is no good way to tell apartscx_move_task() invocations for racing migration to the root cgroup and anautogroup migration.This led to scx_move_task() incorrectly ignoring a migration from non-rootcgroup to an autogroup of the root cgroup triggering the following warning: WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340 ... Call Trace: cgroup_migrate_execute+0x5b1/0x700 cgroup_attach_task+0x296/0x400 __cgroup_procs_write+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0xf0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix it by adding an argument to sched_move_task() that indicates whether themoving is for a cgroup or autogroup migration. After the change,scx_move_task() is called only for cgroup migrations and renamed toscx_cgroup_move_task().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: etas_es58x: fix potential NULL pointer dereference on udev->serialThe driver assumed that es58x_dev->udev->serial could never be NULL.While this is true on commercially available devices, an attackercould spoof the device identity providing a NULL USB serial number.That would trigger a NULL pointer dereference.Add a check on es58x_dev->udev->serial before accessing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocatedFix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() tobail out if skb cannot be allocated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ctucanfd: handle skb allocation failureIf skb allocation fails, the pointer to struct can_frame is NULL. Thisis actually handled everywhere inside ctucan_err_interrupt() except forthe only place.Add the missed NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Validate the persistent meta data subbuf arrayThe meta data for a mapped ring buffer contains an array of indexes of allthe subbuffers. The first entry is the reader page, and the rest of theentries lay out the order of the subbuffers in how the ring buffer linklist is to be created.The validator currently makes sure that all the entries are within therange of 0 and nr_subbufs. But it does not check if there are anyduplicates.While working on the ring buffer, I corrupted this array, where I addedduplicates. The validator did not catch it and created the ring bufferlink list on top of it. Luckily, the corruption was only that the readerpage was also in the writer path and only presented corrupted data but didnot crash the kernel. But if there were duplicates in the writer side,then it could corrupt the ring buffer link list and cause a crash.Create a bitmask array with the size of the number of subbuffers. Thenclear it. When walking through the subbuf array checking to see if theentries are within the range, test if its bit is already set in thesubbuf_mask. If it is, then there is duplicates and fail the validation.If not, set the corresponding bit and continue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not allow mmap() of persistent ring bufferWhen trying to mmap a trace instance buffer that is attached toreserve_mem, it would crash: BUG: unable to handle page fault for address: ffffe97bd00025c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 2862f3067 P4D 2862f3067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:validate_page_before_insert+0x5/0xb0 Code: e2 01 89 d0 c3 cc cc cc cc 66 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 90 0f 1f 44 00 00 <48> 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89 RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246 RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29 RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08 RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000 R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000 FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0 Call Trace: ? __die_body.cold+0x19/0x1f ? __die+0x2e/0x40 ? page_fault_oops+0x157/0x2b0 ? search_module_extables+0x53/0x80 ? validate_page_before_insert+0x5/0xb0 ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70 ? __bad_area_nosemaphore+0x16e/0x1b0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x77/0x90 ? exc_page_fault+0x22b/0x230 ? asm_exc_page_fault+0x2b/0x30 ? validate_page_before_insert+0x5/0xb0 ? vm_insert_pages+0x151/0x400 __rb_map_vma+0x21f/0x3f0 ring_buffer_map+0x21b/0x2f0 tracing_buffers_mmap+0x70/0xd0 __mmap_region+0x6f0/0xbd0 mmap_region+0x7f/0x130 do_mmap+0x475/0x610 vm_mmap_pgoff+0xf2/0x1d0 ksys_mmap_pgoff+0x166/0x200 __x64_sys_mmap+0x37/0x50 x64_sys_call+0x1670/0x1d70 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe reason was that the code that maps the ring buffer pages to user spacehas: page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]);And uses that in: vm_insert_pages(vma, vma->vm_start, pages, &nr_pages);But virt_to_page() does not work with vmap()'d memory which is what thepersistent ring buffer has. It is rather trivial to allow this, but fornow just disable mmap() of instances that have their ring buffer from thereserve_mem option.If an mmap() is performed on a persistent buffer it will return -ENODEVjust like it would if the .mmap field wasn't defined in thefile_operations structure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix panic during interface removalReference counting is used to ensure thatbatadv_hardif_neigh_node and batadv_hard_ifaceare not freed before/duringbatadv_v_elp_throughput_metric_update work isfinished.But there isn't a guarantee that the hard if willremain associated with a soft interface up untilthe work is finished.This fixes a crash triggered by reboot that lookslike this:Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20(the batadv_v_mesh_free call is misleading,and does not actually happen)I was able to make the issue happen more reliablyby changing hardif_neigh->bat_v.metric_work workto be delayed work. This allowed me to track downand confirm the fix.[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: Fix crash on error in gpiochip_get_ngpios()The gpiochip_get_ngpios() uses chip_*() macros to print messages.However these macros rely on gpiodev to be initialised and set,which is not the case when called via bgpio_init(). In such a casethe printing messages will crash on NULL pointer dereference.Replace chip_*() macros by the respective dev_*() ones to avoidsuch crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: bail out when failed to load fw in psp_init_cap_microcode()In function psp_init_cap_microcode(), it should bail out when failed toload firmware, otherwise it may cause invalid memory access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Put the pwq after detaching the rescuer from the poolThe commit 68f83057b913("workqueue: Reap workers via kthread_stop() andremove detach_completion") adds code to reap the normal workers butmistakenly does not handle the rescuer and also removes the code waitingfor the rescuer in put_unbound_pool(), which caused a use-after-free bugreported by Cheung Wall.To avoid the use-after-free bug, the pool's reference must be held untilthe detachment is complete. Therefore, move the code that puts the pwqafter detaching the rescuer from the pool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: fix memleak in certain XDP casesIf the XDP program doesn't result in XDP_PASS then we leak thememory allocated by am65_cpsw_build_skb().It is pointless to allocate SKB memory before running the XDPprogram as we would be wasting CPU cycles for cases other than XDP_PASS.Move the SKB allocation after evaluating the XDP program result.This fixes the memleak. A performance boost is seen for XDP_DROP test.XDP_DROP test:Before: 460256 rx/s 0 err/sAfter: 784130 rx/s 0 err/s
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: check vxlan_vnigroup_init() return valuevxlan_init() must check vxlan_vnigroup_init() successotherwise a crash happens later, spotted by syzbot.Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effbRDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942 unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824 unregister_netdevice_many net/core/dev.c:11866 [inline] unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736 register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901 __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981 vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407 rtnl_newlink_create net/core/rtnetlink.c:3795 [inline] __rtnl_newlink net/core/rtnetlink.c:3906 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockoptIf an AX25 device is bound to a socket by setting the SO_BINDTODEVICEsocket option, a refcount leak will occur in ax25_release().Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")added decrement of device refcounts in ax25_release(). In order for thatto work correctly the refcounts must already be incremented when thedevice is bound to the socket. An AX25 device can be bound to a socketby either calling ax25_bind() or setting SO_BINDTODEVICE socket option.In both cases the refcounts should be incremented, but in fact it is doneonly in ax25_bind().This bug leads to the following issue reported by Syzkaller:================================================================refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Modules linked in:CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ... do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Fix the implementation of ax25_setsockopt() by adding increment ofrefcounts for the new device bound, and decrement of refcounts forthe old unbound device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: sn-f-ospi: Fix division by zeroWhen there is no dummy cycle in the spi-nor commands, both dummy bus cyclebytes and width are zero. Because of the cpu's warning when divided byzero, the warning should be avoided. Return just zero to avoid suchcalculations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-thrustmaster: fix stack-out-of-bounds read in usb_check_int_endpoints()Syzbot[1] has detected a stack-out-of-bounds read of the ep_addr array fromhid-thrustmaster driver. This array is passed to usb_check_int_endpointsfunction from usb.c core driver, which executes a for loop that iteratesover the elements of the passed array. Not finding a null element at the end ofthe array, it tries to read the next, non-existent element, crashing the kernel.To fix this, a 0 element was added at the end of the array to break the forloop.[1] https://syzkaller.appspot.com/bug?extid=9c9179ac46169c56c1ad
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix hang in nfsd4_shutdown_callbackIf nfs4_client is in courtesy state then there is no point to sendthe callback. This causes nfsd4_shutdown_callback to hang sincecl_cb_inflight is not 0. This hang lasts about 15 minutes until TCPnotifies NFSD that the connection was dropped.This patch modifies nfsd4_run_cb_work to skip the RPC call ifnfs4_client is in courtesy state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: corsair-void: Add missing delayed work cancel for headset statusThe cancel_delayed_work_sync() call was missed, causing a use-after-freein corsair_void_remove().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers/migration: Fix off-by-one root mis-connectionBefore attaching a new root to the old root, the children counter of thenew root is checked to verify that only the upcoming CPU's top group havebeen connected to it. However since the recently added commit b729cc1ec21a("timers/migration: Fix another race between hotplug and idle entry/exit")this check is not valid anymore because the old root is pre-accountedas a child to the new root. Therefore after connecting the upcomingCPU's top group to the new root, the children count to be expected mustbe 2 and not 1 anymore.This omission results in the old root to not be connected to the newroot. Then eventually the system may run with more than one top level,which defeats the purpose of a single idle migrator.Also the old root is pre-accounted but not connected upon the new rootcreation. But it can be connected to the new root later on. Thereforethe old root may be accounted twice to the new root. The propagation ofsuch overcommit can end up creating a double final top-level root with agroupmask incorrectly initialized. Although harmless given that the finaltop level roots will never have a parent to walk up to, this oddityopportunistically reported the core issue: WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt Fix the problem by taking the old root into account in the children countof the new root so the connection is not omitted.Also warn when more than one top level group exists to better detectsimilar issues in the future.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/compaction: fix UBSAN shift-out-of-bounds warningsyzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order)in isolate_freepages_block(). The bogus compound_order can be any valuebecause it is union with flags. Add back the MAX_PAGE_ORDER check to fixthe warning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYINGhrtimers are migrated away from the dying CPU to any online target atthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timershandling tasks involved in the CPU hotplug forward progress.However wakeups can still be performed by the outgoing CPU afterCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers beingarmed. Depending on several considerations (crystal ball power managementbased election, earliest timer already enqueued, timer migration enabled ornot), the target may eventually be the current CPU even if offline. If thathappens, the timer is eventually ignored.The most notable example is RCU which had to deal with each and every ofthose wake-ups by deferring them to an online CPU, along with relatedworkarounds:_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)The problem isn't confined to RCU though as the stop machine kthread(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the endof its work through cpu_stop_signal_done() and performs a wake up thateventually arms the deadline server timer: WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_threadInstead of providing yet another bandaid to work around the situation, fixit in the hrtimers infrastructure instead: always migrate away a timer toan online target whenever it is enqueued from an offline CPU.This will also allow to revert all the above RCU disgraceful hacks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "drm/amd/display: Use HW lock mgr for PSR1"This reverts commita2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")Because it may cause system hang while connect with two edp panel.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Drop unmanaged ELP metric workerThe ELP worker needs to calculate new metric values for all neighbors"reachable" over an interface. Some of the used metric sources requirelocks which might need to sleep. This sleep is incompatible with the RCUlist iterator used for the recorded neighbors. The initial approach to workaround of this problem was to queue another work item per neighbor and thenrun this in a new context.Even when this solved the RCU vs might_sleep() conflict, it has a majorproblems: Nothing was stopping the work item in case it is not neededanymore - for example because one of the related interfaces was removed orthe batman-adv module was unloaded - resulting in potential invalid memoryaccesses.Directly canceling the metric worker also has various problems:* cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.* iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)The better approch is to get rid of the per interface neighbor metricworker and handle everything in the interface worker. The original problemsare solved by:* creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context* only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix a use of uninitialized mutexcommit c8347f915e67 ("gpu: host1x: Fix boot regression for Tegra")caused a use of uninitialized mutex leading to below warning whenCONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC are enabled.[ 41.662843] ------------[ cut here ]------------[ 41.663012] DEBUG_LOCKS_WARN_ON(lock->magic != lock)[ 41.663035] WARNING: CPU: 4 PID: 794 at kernel/locking/mutex.c:587 __mutex_lock+0x670/0x878[ 41.663458] Modules linked in: rtw88_8822c(+) bluetooth(+) rtw88_pci rtw88_core mac80211 aquantia libarc4 crc_itu_t cfg80211 tegra194_cpufreq dwmac_tegra(+) arm_dsu_pmu stmmac_platform stmmac pcs_xpcs rfkill at24 host1x(+) tegra_bpmp_thermal ramoops reed_solomon fuse loop nfnetlink xfs mmc_block rpmb_core ucsi_ccg ina3221 crct10dif_ce xhci_tegra ghash_ce lm90 sha2_ce sha256_arm64 sha1_ce sdhci_tegra pwm_fan sdhci_pltfm sdhci gpio_keys rtc_tegra cqhci mmc_core phy_tegra_xusb i2c_tegra tegra186_gpc_dma i2c_tegra_bpmp spi_tegra114 dm_mirror dm_region_hash dm_log dm_mod[ 41.665078] CPU: 4 UID: 0 PID: 794 Comm: (udev-worker) Not tainted 6.11.0-29.31_1538613708.el10.aarch64+debug #1[ 41.665838] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.3.0-gcid-35594366 02/26/2024[ 41.672555] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 41.679636] pc : __mutex_lock+0x670/0x878[ 41.683834] lr : __mutex_lock+0x670/0x878[ 41.688035] sp : ffff800084b77090[ 41.691446] x29: ffff800084b77160 x28: ffffdd4bebf7b000 x27: ffffdd4be96b1000[ 41.698799] x26: 1fffe0002308361c x25: 1ffff0001096ee18 x24: 0000000000000000[ 41.706149] x23: 0000000000000000 x22: 0000000000000002 x21: ffffdd4be6e3c7a0[ 41.713500] x20: ffff800084b770f0 x19: ffff00011841b1e8 x18: 0000000000000000[ 41.720675] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720[ 41.728023] x14: 0000000000000000 x13: 0000000000000001 x12: ffff6001a96eaab3[ 41.735375] x11: 1fffe001a96eaab2 x10: ffff6001a96eaab2 x9 : ffffdd4be4838bbc[ 41.742723] x8 : 00009ffe5691554e x7 : ffff000d4b755593 x6 : 0000000000000001[ 41.749985] x5 : ffff000d4b755590 x4 : 1fffe0001d88f001 x3 : dfff800000000000[ 41.756988] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ec478000[ 41.764251] Call trace:[ 41.766695] __mutex_lock+0x670/0x878[ 41.770373] mutex_lock_nested+0x2c/0x40[ 41.774134] host1x_intr_start+0x54/0xf8 [host1x][ 41.778863] host1x_runtime_resume+0x150/0x228 [host1x][ 41.783935] pm_generic_runtime_resume+0x84/0xc8[ 41.788485] __rpm_callback+0xa0/0x478[ 41.792422] rpm_callback+0x15c/0x1a8[ 41.795922] rpm_resume+0x698/0xc08[ 41.799597] __pm_runtime_resume+0xa8/0x140[ 41.803621] host1x_probe+0x810/0xbc0 [host1x][ 41.807909] platform_probe+0xcc/0x1a8[ 41.811845] really_probe+0x188/0x800[ 41.815347] __driver_probe_device+0x164/0x360[ 41.819810] driver_probe_device+0x64/0x1a8[ 41.823834] __driver_attach+0x180/0x490[ 41.827773] bus_for_each_dev+0x104/0x1a0[ 41.831797] driver_attach+0x44/0x68[ 41.835296] bus_add_driver+0x23c/0x4e8[ 41.839235] driver_register+0x15c/0x3a8[ 41.843170] __platform_register_drivers+0xa4/0x208[ 41.848159] tegra_host1x_init+0x4c/0xff8 [host1x][ 41.853147] do_one_initcall+0xd4/0x380[ 41.856997] do_init_module+0x1dc/0x698[ 41.860758] load_module+0xc70/0x1300[ 41.864435] __do_sys_init_module+0x1a8/0x1d0[ 41.868721] __arm64_sys_init_module+0x74/0xb0[ 41.873183] invoke_syscall.constprop.0+0xdc/0x1e8[ 41.877997] do_el0_svc+0x154/0x1d0[ 41.881671] el0_svc+0x54/0x140[ 41.884820] el0t_64_sync_handler+0x120/0x130[ 41.889285] el0t_64_sync+0x1a4/0x1a8[ 41.892960] irq event stamp: 69737[ 41.896370] hardirqs last enabled at (69737): [] _raw_spin_unlock_irqrestore+0x44/0xe8[ 41.905739] hardirqs last disabled at (69736):---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: don't revert iter for -EIOCBQUEUEDblkdev_read_iter() has a few odd checks, like gating the position andcount adjustment on whether or not the result is bigger-than-or-equal tozero (where bigger than makes more sense), and not checking the returnvalue of blkdev_direct_IO() before doing an iov_iter_revert(). Thelatter can lead to attempting to revert with a negative value, whichwhen passed to iov_iter_revert() as an unsigned value will lead tothrowing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.Be sane and don't revert for -EIOCBQUEUED, like what is done in otherspots.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:seccomp: passthrough uretprobe systemcall without filteringWhen attaching uretprobes to processes running inside docker, the attachedprocess is segfaulted when encountering the retprobe.The reason is that now that uretprobe is a system call the default seccompfilters in docker block it as they only allow a specific set of knownsyscalls. This is true for other userspace applications which use seccompto control their syscall surface.Since uretprobe is a "kernel implementation detail" system call which isnot used by userspace application code directly, it is impractical andthere's very little point in forcing all userspace applications toexplicitly allow it in order to avoid crashing tracked processes.Pass this systemcall through seccomp without depending on configuration.Note: uretprobe is currently only x86_64 and isn't expected to ever besupported in i386.[kees: minimized changes for easier backporting, tweaked commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_midi: fix MIDI Streaming descriptor lengthsWhile the MIDI jacks are configured correctly, and the MIDIStreamingendpoint descriptors are filled with the correct information,bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.This does not matter when the numbers of in and out ports are equal, butwhen they differ the host will receive broken descriptors withuninitialized stack memory leaking into the descriptor for whichevervalue is smaller.The precise meaning of "in" and "out" in the port counts is not clearlydefined and can be confusing. But elsewhere the driver consistentlyuses this to match the USB meaning of IN and OUT viewed from the host,so that "in" ports send data to the host and "out" ports receive datafrom it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: reallocate buf lists on upgradeIORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if itwas created for legacy selected buffer and has been emptied. It violatesthe requirement that most of the field should stay stable after publish.Always reallocate it instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal/netlink: Prevent userspace segmentation fault by adjusting UAPI headerThe intel-lpmd tool [1], which uses the THERMAL_GENL_ATTR_CPU_CAPABILITYattribute to receive HFI events from kernel space, encounters asegmentation fault after commit 1773572863c4 ("thermal: netlink: Add thecommands and the events for the thresholds").The issue arises because the THERMAL_GENL_ATTR_CPU_CAPABILITY raw valuewas changed while intel_lpmd still uses the old value.Although intel_lpmd can be updated to check the THERMAL_GENL_VERSION anduse the appropriate THERMAL_GENL_ATTR_CPU_CAPABILITY value, the commititself is questionable.The commit introduced a new element in the middle of enum thermal_genl_attr,which affects many existing attributes and introduces potential risksand unnecessary maintenance burdens for userspace thermal netlink eventusers.Solve the issue by moving the newly introducedTHERMAL_GENL_ATTR_TZ_PREV_TEMP attribute to the end of theenum thermal_genl_attr. This ensures that all existing thermal genericnetlink attributes remain unaffected.[ rjw: Subject edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq/amd-pstate: Fix cpufreq_policy ref countingamd_pstate_update_limits() takes a cpufreq_policy reference but doesn'tdecrement the refcount in one of the exit paths, fix that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amdkfd: properly free gang_ctx_bo when failed to init user queueThe destructor of a gtt bo is declared asvoid amdgpu_amdkfd_free_gtt_mem(struct amdgpu_device *adev, void **mem_obj);Which takes void** as the second parameter.GCC allows passing void* to the function because void* can be implicitlycasted to any other types, so it can pass compiling.However, passing this void* parameter into the function'sexecution process(which expects void** and dereferencing void**)will result in errors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: avoid garbage value in panthor_ioctl_dev_query()'priorities_info' is uninitialized, and the uninitialized value is copiedto user object when calling PANTHOR_UOBJ_SET(). Using memset to initialize'priorities_info' to avoid this garbage value problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Add check for next_buffer in receive_encrypted_standard()Add check for the return value of cifs_buf_get() and cifs_small_buf_get()in receive_encrypted_standard() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acct: perform last write from workqueueIn [1] it was reported that the acct(2) system call can be used totrigger NULL deref in cases where it is set to write to a file thattriggers an internal lookup. This can e.g., happen when pointing acc(2)to /sys/power/resume. At the point the where the write to this filehappens the calling task has already exited and called exit_fs(). Alookup will thus trigger a NULL-deref when accessing current->fs.Reorganize the code so that the the final write happens from theworkqueue but with the caller's credentials. This preserves the(strange) permission model and has almost no regression risk.This api should stop to exist though.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()The nullity of sps->cstream should be checked similarly as it is done insof_set_stream_data_offset() function.Assuming that it is not NULL if sps->stream is NULL is incorrect and canlead to NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()Add check for the return value of nfp_app_ctrl_msg_alloc() innfp_bpf_cmsg_alloc() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Use spin_lock_irqsave() in interruptible contextspin_lock/unlock() functions used in interrupt contexts couldresult in a deadlock, as seen in GitLab issue #13399,which occurs when interrupt comes in while holding a lock.Try to remedy the problem by saving irq state before spin lockacquisition.v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej)v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message(cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: Fix crash when a namespace is disabledThe namespace percpu counter protects pending I/O, and we canonly safely diable the namespace once the counter drop to zero.Otherwise we end up with a crash when running blktests/nvme/058(eg for loop transport):[ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI[ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f][ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232[ 2352.930438] [ T53909] Tainted: [W]=WARN[ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop][ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180as the queue is already torn down when calling submit_bio();So we need to init the percpu counter in nvmet_ns_enable(), andwait for it to drop to zero in nvmet_ns_disable() to avoid havingI/O pending after the namespace has been disabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix softlockup in arena_map_free on 64k page kernelOn an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,arena_htab tests cause a segmentation fault and soft lockup.The same failure is not observed with 4k pages on aarch64.It turns out arena_map_free() is callingapply_to_existing_page_range() with the address returned bybpf_arena_get_kern_vm_start(). If this address is not page-alignedthe code ends up calling apply_to_pte_range() with that unalignedaddress causing soft lockup.Fix it by round up GUARD_SZ to PAGE_SIZE << 1 so that thedivision by 2 in bpf_arena_get_kern_vm_start() returnsa page-aligned value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Add rx_skb of kfree_skb to raw_tp_null_args[].Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0]in trace_kfree_skb if the prog does not check if rx_sk is NULL.Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") addedrx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL.Let's add kfree_skb to raw_tp_null_args[] to let the BPF verifiervalidate such a prog and prevent the issue.Now we fail to load such a prog: libbpf: prog 'drop': -- BEGIN PROG LOAD LOG -- 0: R1=ctx() R10=fp0 ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21 0: (79) r3 = *(u64 *)(r1 +24) func 'kfree_skb' arg3 has btf_id 5253 type STRUCT 'sock' 1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1) ; bpf_printk("sk: %d, %d\n", sk, sk->__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24 1: (69) r4 = *(u16 *)(r3 +16) R3 invalid mem access 'trusted_ptr_or_null_' processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG --Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tparguments with PTR_MAYBE_NULL").[0]:BUG: kernel NULL pointer dereference, address: 0000000000000010 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0 P4D 0PREEMPT SMPRIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2dCall Trace: ? __die+0x1f/0x60 ? page_fault_oops+0x148/0x420 ? search_bpf_extables+0x5b/0x70 ? fixup_exception+0x27/0x2c0 ? exc_page_fault+0x75/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d bpf_trace_run4+0x68/0xd0 ? unix_stream_connect+0x1f4/0x6f0 sk_skb_reason_drop+0x90/0x120 unix_stream_connect+0x1f4/0x6f0 __sys_connect+0x7f/0xb0 __x64_sys_connect+0x14/0x20 do_syscall_64+0x47/0xc30 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: avoid holding freeze_mutex during mmap operationWe use map->freeze_mutex to prevent races between map_freeze() andmemory mapping BPF map contents with writable permissions. The way wenaively do this means we'll hold freeze_mutex for entire duration of allthe mm and VMA manipulations, which is completely unnecessary. This canpotentially also lead to deadlocks, as reported by syzbot in [0].So, instead, hold freeze_mutex only during writeability checks, bump(proactively) "write active" count for the map, unlock the mutex andproceed with mmap logic. And only if something went wrong during mmaplogic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sockmap, vsock: For connectible sockets allow only connectedsockmap expects all vsocks to have a transport assigned, which is expressedin vsock_proto::psock_update_sk_prot(). However, there is an edge casewhere an unconnected (connectible) socket may lose its previously assignedtransport. This is handled with a NULL check in the vsock/BPF recv path.Another design detail is that listening vsocks are not supposed to have anytransport assigned at all. Which implies they are not supported by thesockmap. But this is complicated by the fact that a socket, beforeswitching to TCP_LISTEN, may have had some transport assigned during afailed connect() attempt. Hence, we may end up with a listening vsock in asockmap, which blows up quickly:KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+Workqueue: vsock-loopback vsock_loopback_workRIP: 0010:vsock_read_skb+0x4b/0x90Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30For connectible sockets, instead of relying solely on the state ofvsk->transport, tell sockmap to only allow those representing establishedconnections. This aligns with the behaviour for AF_INET and AF_UNIX.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ism: add release function for struct deviceAccording to device_release() in /drivers/base/core.c,a device without a release function is a broken deviceand must be fixed.The current code directly frees the device after calling device_add()without waiting for other kernel parts to release their references.Thus, a reference could still be held to a struct device,e.g., by sysfs, leading to potential use-after-freeissues if a proper release function is not set.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_api: fix error handling causing NULL dereferencetcf_exts_miss_cookie_base_alloc() calls xa_alloc_cyclic() which canreturn 1 if the allocation succeeded after wrapping. This was treated asan error, with value 1 returned to caller tcf_exts_init_ex() which setsexts->actions to NULL and returns 1 to caller fl_change().fl_change() treats err == 1 as success, calling tcf_exts_validate_ex()which calls tcf_action_init() with exts->actions as argument, where itis dereferenced.Example trace:BUG: kernel NULL pointer dereference, address: 0000000000000000CPU: 114 PID: 16151 Comm: handler114 Kdump: loaded Not tainted 5.14.0-503.16.1.el9_5.x86_64 #1RIP: 0010:tcf_action_init+0x1f8/0x2c0Call Trace: tcf_action_init+0x1f8/0x2c0 tcf_exts_validate_ex+0x175/0x190 fl_change+0x537/0x1120 [cls_flower]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)->geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let's call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: f_midi: f_midi_complete to call queue_workWhen using USB MIDI, a lock is attempted to be acquired twice through are-entrant call to f_midi_transmit, causing a deadlock.Fix it by using queue_work() to schedule the inner f_midi_transmit() viaa high priority work queue from the completion handler.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/zswap: fix inconsistency when zswap_store_page() failsCommit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()")skips charging any zswap entries when it failed to zswap the entire folio.However, when some base pages are zswapped but it failed to zswap theentire folio, the zswap operation is rolled back. When freeing zswapentries for those pages, zswap_entry_free() uncharges the zswap entriesthat were not previously charged, causing zswap charging to becomeinconsistent.This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot The two warnings are: in mm/memcontrol.c:163, function obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); in mm/page_counter.c:60, function page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages))zswap_stored_pages also becomes inconsistent in the same way.As suggested by Kanchana, increment zswap_stored_pages and charge zswapentries within zswap_store_page() when it succeeds. This way,zswap_entry_free() will decrement the counter and uncharge the entrieswhen it failed to zswap the entire folio.While this could potentially be optimized by batching objcg charging andincrementing the counter, let's focus on fixing the bug this time andleave the optimization for later after some evaluation.After resolving the inconsistency, the warnings disappear.[42.hyeyoo@gmail.com: refactor zswap_store_page()]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()If migration succeeded, we calledfolio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from theold to the new folio. This will set memcg_data of the old folio to 0.Similarly, if migration failed, memcg_data of the dst folio is left unset.If we call folio_putback_lru() on such folios (memcg_data == 0), we willadd the folio to be freed to the LRU, making memcg code unhappy. Runningthe hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80Likely, nothing else goes wrong: putting the last folio reference willremove the folio from the LRU again. So besides memcg complaining, addingthe folio to be freed to the LRU is just an unnecessary step.The new flow resembles what we have in migrate_folio_move(): add the dstto the lru, rem---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: fix incorrect initialization orderSyzkaller reports the following bug:BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7RIP: 0033:0x7f3f9815aee9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768If drop_monitor is built as a kernel module, syzkaller may have timeto send a netlink NET_DM_CMD_START message during the module loading.This will call the net_dm_monitor_start() function that usesa spinlock that has not yet been initialized.To fix this, let's place resource initialization above the registrationof a generic netlink family.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: prevent opcode speculationsqe->opcode is used for different tables, make sure we santitise itagainst speculations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: drop secpath at the same time as we currently drop dstXiumei reported hitting the WARN in xfrm6_tunnel_net_exit whilerunning tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netnsThe xfrm_state found on spi_byaddr was not deleted at the time wedelete the netns, because we still have a reference on it. Thislingering reference comes from a secpath (which holds a ref on thexfrm_state), which is still attached to an skb. This skb is notleaked, it ends up on sk_receive_queue and then gets defer-free'd byskb_attempt_defer_free.The problem happens when we defer freeing an skb (push it on one CPU'sdefer_list), and don't flush that list before the netns is deleted. Inthat case, we still have a reference on the xfrm_state that we don'texpect at this point.We already drop the skb's dst in the TCP receive path when it's nolonger needed, so let's also drop the secpath. At this point,tcp_filter has already called into the LSM hooks that may require thesecpath, so it should not be needed anymore. However, in some of thoseplaces, the MPTCP extension has just been attached to the skb, so wecannot simply drop all extensions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().Brad Spengler reported the list_del() corruption splat ingtp_net_exit_batch_rtnl(). [0]Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netnsdismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()to destroy devices in each netns as done in geneve and ip tunnels.However, this could trigger ->dellink() twice for the same device during->exit_batch_rtnl().Say we have two netns A & B and gtp device B that resides in netns B butwhose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink().gtp_dellink() cleans up the device's hash table, unlinks the dev fromgn->gtp_dev_list, and calls unregister_netdevice_queue().Basically, calling gtp_dellink() multiple times is fine unlessCONFIG_DEBUG_LIST is enabled.Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() anddelegate the destruction to default_device_exit_batch() as donein bareudp.[0]:list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)kernel BUG at lib/list_debug.c:58!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1Tainted: [T]=RANDSTRUCTHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: netns cleanup_netRIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08RBX: kasan shadow of 0x0RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360dCall Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOCErhard reported the following KASAN hit while booting his PowerMac G4with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================f8 corresponds to KASAN_VMALLOC_INVALID which means the area is notinitialised hence not supposed to be used yet.Powerpc text patching infrastructure allocates a virtual memory areausing get_vm_area() and flags it as VM_ALLOC. But that flag is meantto be used for vmalloc() and vmalloc() allocated memory is notsupposed to be used before a call to __vmalloc_node_range() which isnever called for that area.That went undetected until commit e4137f08816b ("mm, kasan, kmsan:instrument copy_from/to_kernel_nofault")The area allocated by text_area_cpu_up() is not vmalloc memory, it ismapped directly on demand when needed by map_kernel_page(). There isno VM flag corresponding to such usage, so just pass no flag. That waythe area will be unpoisonned and usable immediately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()KMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. Thecause of the issue was that eth_skb_pkt_type() accessed skb's datathat didn't contain an Ethernet header. This occurs whenbpf_prog_test_run_xdp() passes an invalid value as the user_dataargument to bpf_test_init().Fix this by returning an error when user_data is less than ETH_HLEN inbpf_test_init(). Additionally, remove the check for "if (user_size >size)" as it is unnecessary.[1]BUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]BUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165 eth_skb_pkt_type include/linux/etherdevice.h:627 [inline] eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165 __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635 xdp_recv_frames net/bpf/test_run.c:272 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318 bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371 __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777 __do_sys_bpf kernel/bpf/syscall.c:5866 [inline] __se_sys_bpf kernel/bpf/syscall.c:5864 [inline] __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864 x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: free_pages_prepare mm/page_alloc.c:1056 [inline] free_unref_page+0x156/0x1320 mm/page_alloc.c:2657 __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838 bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline] ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235 bpf_map_free kernel/bpf/syscall.c:838 [inline] bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310 worker_thread+0xedf/0x1550 kernel/workqueue.c:3391 kthread+0x535/0x6b0 kernel/kthread.c:389 ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: allow small head cache usage with large MAX_SKB_FRAGS valuesSabrina reported the following splat: WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0 Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe <0f> 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48 RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6 RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168 R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007 FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: gro_cells_init+0x1ba/0x270 xfrm_input_init+0x4b/0x2a0 xfrm_init+0x38/0x50 ip_rt_init+0x2d7/0x350 ip_init+0xf/0x20 inet_init+0x406/0x590 do_one_initcall+0x9d/0x2e0 do_initcalls+0x23b/0x280 kernel_init_freeable+0x445/0x490 kernel_init+0x20/0x1d0 ret_from_fork+0x46/0x80 ret_from_fork_asm+0x1a/0x30 irq event stamp: 584330 hardirqs last enabled at (584338): [] __up_console_sem+0x77/0xb0 hardirqs last disabled at (584345): [] __up_console_sem+0x5c/0xb0 softirqs last enabled at (583242): [] netlink_insert+0x14d/0x470 softirqs last disabled at (583754): [] netif_napi_add_weight_locked+0x77d/0xba0on kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)is smaller than GRO_MAX_HEAD.Such built additionally contains the revert of the single page frag cacheso that napi_get_frags() ends up using the page frag allocator, triggeringthe splat.Note that the underlying issue is independent from the mentionedrevert; address it ensuring that the small head cache will fit either TCPand GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()to select kmalloc() usage for any allocation fitting such cache.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Disable KASAN report during patching via temporary mmErhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:[ 12.028126] ==================================================================[ 12.028198] BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0[ 12.028260] Write of size 8 at addr 0000187e458f2000 by task systemd/1[ 12.028346] CPU: 87 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.13.0-P9-dirty #3[ 12.028408] Tainted: [T]=RANDSTRUCT[ 12.028446] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV[ 12.028500] Call Trace:[ 12.028536] [c000000008dbf3b0] [c000000001656a48] dump_stack_lvl+0xbc/0x110 (unreliable)[ 12.028609] [c000000008dbf3f0] [c0000000006e2fc8] print_report+0x6b0/0x708[ 12.028666] [c000000008dbf4e0] [c0000000006e2454] kasan_report+0x164/0x300[ 12.028725] [c000000008dbf600] [c0000000006e54d4] kasan_check_range+0x314/0x370[ 12.028784] [c000000008dbf640] [c0000000006e6310] __kasan_check_write+0x20/0x40[ 12.028842] [c000000008dbf660] [c000000000578e8c] copy_to_kernel_nofault+0x8c/0x1a0[ 12.028902] [c000000008dbf6a0] [c0000000000acfe4] __patch_instructions+0x194/0x210[ 12.028965] [c000000008dbf6e0] [c0000000000ade80] patch_instructions+0x150/0x590[ 12.029026] [c000000008dbf7c0] [c0000000001159bc] bpf_arch_text_copy+0x6c/0xe0[ 12.029085] [c000000008dbf800] [c000000000424250] bpf_jit_binary_pack_finalize+0x40/0xc0[ 12.029147] [c000000008dbf830] [c000000000115dec] bpf_int_jit_compile+0x3bc/0x930[ 12.029206] [c000000008dbf990] [c000000000423720] bpf_prog_select_runtime+0x1f0/0x280[ 12.029266] [c000000008dbfa00] [c000000000434b18] bpf_prog_load+0xbb8/0x1370[ 12.029324] [c000000008dbfb70] [c000000000436ebc] __sys_bpf+0x5ac/0x2e00[ 12.029379] [c000000008dbfd00] [c00000000043a228] sys_bpf+0x28/0x40[ 12.029435] [c000000008dbfd20] [c000000000038eb4] system_call_exception+0x334/0x610[ 12.029497] [c000000008dbfe50] [c00000000000c270] system_call_vectored_common+0xf0/0x280[ 12.029561] --- interrupt: 3000 at 0x3fff82f5cfa8[ 12.029608] NIP: 00003fff82f5cfa8 LR: 00003fff82f5cfa8 CTR: 0000000000000000[ 12.029660] REGS: c000000008dbfe80 TRAP: 3000 Tainted: G T (6.13.0-P9-dirty)[ 12.029735] MSR: 900000000280f032 CR: 42004848 XER: 00000000[ 12.029855] IRQMASK: 0 GPR00: 0000000000000169 00003fffdcf789a0 00003fff83067100 0000000000000005 GPR04: 00003fffdcf78a98 0000000000000090 0000000000000000 0000000000000008 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 00003fff836ff7e0 c000000000010678 0000000000000000 GPR16: 0000000000000000 0000000000000000 00003fffdcf78f28 00003fffdcf78f90 GPR20: 0000000000000000 0000000000000000 0000000000000000 00003fffdcf78f80 GPR24: 00003fffdcf78f70 00003fffdcf78d10 00003fff835c7239 00003fffdcf78bd8 GPR28: 00003fffdcf78a98 0000000000000000 0000000000000000 000000011f547580[ 12.030316] NIP [00003fff82f5cfa8] 0x3fff82f5cfa8[ 12.030361] LR [00003fff82f5cfa8] 0x3fff82f5cfa8[ 12.030405] --- interrupt: 3000[ 12.030444] ==================================================================Commit c28c15b6d28a ("powerpc/code-patching: Use temporary mm forRadix MMU") is inspired from x86 but unlike x86 is doesn't disableKASAN reports during patching. This wasn't a problem at the beginingbecause __patch_mem() is not instrumented.Commit 465cabc97b42 ("powerpc/code-patching: introducepatch_instructions()") use copy_to_kernel_nofault() to copy severalinstructions at once. But when using temporary mm the destination isnot regular kernel memory but a kind of kernel-like memory locatedin user address space. ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiersOther, non DAI copier widgets could have the same stream name (sname) asthe ALH copier and in that case the copier->data is NULL, no alh_data isattached, which could lead to NULL pointer dereference.We could check for this NULL pointer in sof_ipc4_prepare_copier_module()and avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai()will miscalculate the ALH device count, causing broken audio.The correct fix is to harden the matching logic by making sure that the1. widget is a DAI widget - so dai = w->private is valid2. the dai (and thus the copier) is ALH copier
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix supplicant wait loopOP-TEE supplicant is a user-space daemon and it's possible for itbe hung or crashed or killed in the middle of processing an OP-TEERPC call. It becomes more complicated when there is incorrect shutdownordering of the supplicant process vs the OP-TEE client application whichcan eventually lead to system hang-up waiting for the closure of theclient application.Allow the client process waiting in kernel for supplicant response tobe killed rather than indefinitely waiting in an unkillable state. Also,a normal uninterruptible wait should not have resulted in the hung-taskwatchdog getting triggered, but the endless loop would.This fixes issues observed during system reboot/shutdown when supplicantgot hung for some reason or gets crashed/killed which lead to clientgetting hung in an unkillable state. It in turn lead to system being inhung up state requiring hard power off/on to recover.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efi: Don't map the entire mokvar table to determine its sizeCurrently, when validating the mokvar table, we (re)map the entire tableon each iteration of the loop, adding space as we discover new entries.If the table grows over a certain size, this fails due to limitations ofearly_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.Mapping the entire structure isn't actually necessary, as we don't everneed more than one entry header mapped at once.Changes efi_mokvar_table_init() to only map each entry header, not theentire table, when determining the table size. Since we're not mappingany data past the variable name, it also changes the code to enforcethat each variable name is NUL terminated, rather than attempting toverify it in place.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: bsg: Fix crash when arpmb command failsIf the device doesn't support arpmb we'll crash due to copying user data inbsg_transport_sg_io_fn().In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do notset the job's reply_len.Memory crash backtrace:3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -224,1308,531166555,-;Call Trace:4,1309,531166559,-; 4,1310,531166565,-; ? show_regs+0x6d/0x804,1311,531166575,-; ? die+0x37/0xa04,1312,531166583,-; ? do_trap+0xd4/0xf04,1313,531166593,-; ? do_error_trap+0x71/0xb04,1314,531166601,-; ? usercopy_abort+0x6c/0x804,1315,531166610,-; ? exc_invalid_op+0x52/0x804,1316,531166622,-; ? usercopy_abort+0x6c/0x804,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x204,1318,531166643,-; ? usercopy_abort+0x6c/0x804,1319,531166652,-; __check_heap_object+0xe3/0x1204,1320,531166661,-; check_heap_object+0x185/0x1d04,1321,531166670,-; __check_object_size.part.0+0x72/0x1504,1322,531166679,-; __check_object_size+0x23/0x304,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-integrity: Avoid divide by zero in table status in Inline modeIn Inline mode, the journal is unused, and journal_sectors is zero.Calculating the journal watermark requires dividing by journal_sectors,which should be done only if the journal is configured.Otherwise, a simple table query (dmsetup table) can cause OOPS.This bug did not show on some systems, perhaps only due tocompiler optimization.On my 32-bit testing machine, this reliably crashes with the following: : Oops: divide error: 0000 [#1] PREEMPT SMP : CPU: 0 UID: 0 PID: 2450 Comm: dmsetup Not tainted 6.14.0-rc2+ #959 : EIP: dm_integrity_status+0x2f8/0xab0 [dm_integrity] ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: always handle address removal under msk socket lockSyzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088Indeed the PM can try to send a RM_ADDR over a msk without acquiringfirst the msk socket lock.The bugged code-path comes from an early optimization: when thereare no subflows, the PM should (usually) not send RM_ADDRnotifications.The above statement is incorrect, as without locks another processcould concur---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix suspicious RCU usageCommit ("iommu/vt-d: Allocate DMAR fault interruptslocally") moved the call to enable_drhd_fault_handling() to a codepath that does not hold any lock while traversing the drhd list. Fixit by ensuring the dmar_global_lock lock is held when traversing thedrhd list.Without this fix, the following warning is triggered: ============================= WARNING: suspicious RCU usage 6.14.0-rc3 #55 Not tainted ----------------------------- drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55 Call Trace: dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Holding the lock in enable_drhd_fault_handling() triggers a lockdep splatabout a possible deadlock between dmar_global_lock and cpu_hotplug_lock.This is avoided by not holding dmar_global_lock when callingiommu_device_register(), which initiates the device probe process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: npcm: disable interrupt enable bit before devm_request_irqThe customer reports that there is a soft lockup issue related tothe i2c driver. After checking, the i2c module was doing a tx transferand the bmc machine reboots in the middle of the i2c transaction, the i2cmodule keeps the status without being reset.Due to such an i2c module status, the i2c irq handler keeps gettingtriggered since the i2c irq handler is registered in the kernel bootingprocess after the bmc machine is doing a warm rebooting.The continuous triggering is stopped by the soft lockup watchdog timer.Disable the interrupt enable bit in the i2c module before callingdevm_request_irq to fix this issue since the i2c relative status bitis read-only.Here is the soft lockup log.[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1][ 28.183351] Modules linked in:[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 28.208128] pc : __do_softirq+0xb0/0x368[ 28.212055] lr : __do_softirq+0x70/0x368[ 28.215972] sp : ffffff8035ebca00[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40[ 28.290611] Call trace:[ 28.293052] __do_softirq+0xb0/0x368[ 28.296625] __irq_exit_rcu+0xe0/0x100[ 28.300374] irq_exit+0x14/0x20[ 28.303513] handle_domain_irq+0x68/0x90[ 28.307440] gic_handle_irq+0x78/0xb0[ 28.311098] call_on_irq_stack+0x20/0x38[ 28.315019] do_interrupt_handler+0x54/0x5c[ 28.319199] el1_interrupt+0x2c/0x4c[ 28.322777] el1h_64_irq_handler+0x14/0x20[ 28.326872] el1h_64_irq+0x74/0x78[ 28.330269] __setup_irq+0x454/0x780[ 28.333841] request_threaded_irq+0xd0/0x1b4[ 28.338107] devm_request_threaded_irq+0x84/0x100[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0[ 28.346990] platform_probe+0x6c/0xc4[ 28.350653] really_probe+0xcc/0x45c[ 28.354227] __driver_probe_device+0x8c/0x160[ 28.358578] driver_probe_device+0x44/0xe0[ 28.362670] __driver_attach+0x124/0x1d0[ 28.366589] bus_for_each_dev+0x7c/0xe0[ 28.370426] driver_attach+0x28/0x30[ 28.373997] bus_add_driver+0x124/0x240[ 28.377830] driver_register+0x7c/0x124[ 28.381662] __platform_driver_register+0x2c/0x34[ 28.386362] npcm_i2c_init+0x3c/0x5c[ 28.389937] do_one_initcall+0x74/0x230[ 28.393768] kernel_init_freeable+0x24c/0x2b4[ 28.398126] kernel_init+0x28/0x130[ 28.401614] ret_from_fork+0x10/0x20[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks[ 28.411011] SMP: stopping secondary CPUs[ 28.414933] Kernel Offset: disabled[ 28.418412] CPU features: 0x00000000,00000802[ 28.427644] Rebooting in 20 seconds..
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free on inode when scanning root during em shrinkingAt btrfs_scan_root() we are accessing the inode's root (and fs_info) in acall to btrfs_fs_closing() after we have scheduled the inode for a delayediput, and that can result in a use-after-free on the inode in case thecleaner kthread does the iput before we dereference the inode in the callto btrfs_fs_closing().Fix this by using the fs_info stored already in a local variable insteadof doing inode->root->fs_info.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/userptr: fix EFAULT handlingCurrently we treat EFAULT from hmm_range_fault() as a non-fatal errorwhen called from xe_vm_userptr_pin() with the idea that we want to avoidkilling the entire vm and chucking an error, under the assumption thatthe user just did an unmap or something, and has no intention ofactually touching that memory from the GPU. At this point we havealready zapped the PTEs so any access should generate a page fault, andif the pin fails there also it will then become fatal.However it looks like it's possible for the userptr vma to still be onthe rebind list in preempt_rebind_work_func(), if we had to retry thepin again due to something happening in the caller before we did therebind step, but in the meantime needing to re-validate the userptr andthis time hitting the EFAULT.This explains an internal user report of hitting:[ 191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe][ 191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738690] Call Trace:[ 191.738692] [ 191.738694] ? show_regs+0x69/0x80[ 191.738698] ? __warn+0x93/0x1a0[ 191.738703] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738759] ? report_bug+0x18f/0x1a0[ 191.738764] ? handle_bug+0x63/0xa0[ 191.738767] ? exc_invalid_op+0x19/0x70[ 191.738770] ? asm_exc_invalid_op+0x1b/0x20[ 191.738777] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe][ 191.738834] ? ret_from_fork_asm+0x1a/0x30[ 191.738849] bind_op_prepare+0x105/0x7b0 [xe][ 191.738906] ? dma_resv_reserve_fences+0x301/0x380[ 191.738912] xe_pt_update_ops_prepare+0x28c/0x4b0 [xe][ 191.738966] ? kmemleak_alloc+0x4b/0x80[ 191.738973] ops_execute+0x188/0x9d0 [xe][ 191.739036] xe_vm_rebind+0x4ce/0x5a0 [xe][ 191.739098] ? trace_hardirqs_on+0x4d/0x60[ 191.739112] preempt_rebind_work_func+0x76f/0xd00 [xe]Followed by NPD, when running some workload, since the sg was neveractually populated but the vma is still marked for rebind when it shouldbe skipped for this special EFAULT case. This is confirmed to fix theuser report.v2 (MattB): - Move earlier.v3 (MattB): - Update the commit message to make it clear that this indeed fixes the issue.(cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: Reject the shared zeropage in uprobe_write_opcode()We triggered the following crash in syzkaller tests: BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1The following syzkaller test case can be used to reproduce: r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)The cause is that zero pfn is set to the PTE without increasing the RSScount in mfill_atomic_pte_zeropage() and the refcount of zero folio doesnot increase accordingly. Then, the operation on the same pfn is performedin uprobe_write_opcode()->__replace_page() to unconditional decrease theRSS count and old_folio's refcount.Therefore, two bugs are introduced: 1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count". 2. The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".There is more, the following warning could also theoretically be triggered: __replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)Considering that uprobe hit on the zero folio is a very rare case, justreject zero old folio immediately after get_user_page_vma_remote().[ mingo: Cleaned up the changelog ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix vport QoS cleanup on errorWhen enabling vport QoS fails, the scheduling node was never freed,causing a leak.Add the missing free and reset the vport scheduling node pointer toNULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix deinitializing VF in error pathIf ice_ena_vfs() fails after calling ice_create_vf_entries(), it freesall VFs without removing them from snapshot PF-VF mailbox list, leadingto list corruption.Reproducer: devlink dev eswitch set $PF1_PCI mode switchdev ip l s $PF1 up ip l s $PF1 promisc on sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfs sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfsTrace (minimized): list_add corruption. next->prev should be prev (ffff8882e241c6f0), but was 0000000000000000. (next=ffff888455da1330). kernel BUG at lib/list_debug.c:29! RIP: 0010:__list_add_valid_or_report+0xa6/0x100 ice_mbx_init_vf_info+0xa7/0x180 [ice] ice_initialize_vf_entry+0x1fa/0x250 [ice] ice_sriov_configure+0x8d7/0x1520 [ice] ? __percpu_ref_switch_mode+0x1b1/0x5d0 ? __pfx_ice_sriov_configure+0x10/0x10 [ice]Sometimes a KASAN report can be seen instead with a similar stack trace: BUG: KASAN: use-after-free in __list_add_valid_or_report+0xf1/0x100VFs are added to this list in ice_mbx_init_vf_info(), but only removedin ice_free_vfs(). Move the removing to ice_free_vf_entries(), which isalso being called in other places where VFs are being removed (includingice_free_vfs() itself).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: better track kernel sockets lifetimeWhile kernel sockets are dismantled during pernet_operations->exit(),their freeing can be delayed by any tx packets still held in qdiscor device queues, due to skb_set_owner_w() prior calls.This then trigger the following warning from ref_tracker_dir_exit() [1]To fix this, make sure that kernel sockets own a reference on net->passive.Add sk_net_refcnt_upgrade() helper, used whenever a kernel socketis converted to a refcounted one.[1][ 136.263918][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at[ 136.263918][ T35] sk_alloc+0x2b3/0x370[ 136.263918][ T35] inet6_create+0x6ce/0x10f0[ 136.263918][ T35] __sock_create+0x4c0/0xa30[ 136.263918][ T35] inet_ctl_sock_create+0xc2/0x250[ 136.263918][ T35] igmp6_net_init+0x39/0x390[ 136.263918][ T35] ops_init+0x31e/0x590[ 136.263918][ T35] setup_net+0x287/0x9e0[ 136.263918][ T35] copy_net_ns+0x33f/0x570[ 136.263918][ T35] create_new_namespaces+0x425/0x7b0[ 136.263918][ T35] unshare_nsproxy_namespaces+0x124/0x180[ 136.263918][ T35] ksys_unshare+0x57d/0xa70[ 136.263918][ T35] __x64_sys_unshare+0x38/0x40[ 136.263918][ T35] do_syscall_64+0xf3/0x230[ 136.263918][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 136.263918][ T35][ 136.343488][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at[ 136.343488][ T35] sk_alloc+0x2b3/0x370[ 136.343488][ T35] inet6_create+0x6ce/0x10f0[ 136.343488][ T35] __sock_create+0x4c0/0xa30[ 136.343488][ T35] inet_ctl_sock_create+0xc2/0x250[ 136.343488][ T35] ndisc_net_init+0xa7/0x2b0[ 136.343488][ T35] ops_init+0x31e/0x590[ 136.343488][ T35] setup_net+0x287/0x9e0[ 136.343488][ T35] copy_net_ns+0x33f/0x570[ 136.343488][ T35] create_new_namespaces+0x425/0x7b0[ 136.343488][ T35] unshare_nsproxy_namespaces+0x124/0x180[ 136.343488][ T35] ksys_unshare+0x57d/0xa70[ 136.343488][ T35] __x64_sys_unshare+0x38/0x40[ 136.343488][ T35] do_syscall_64+0xf3/0x230[ 136.343488][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Fix the page details for the srq created by kernel consumersWhile using nvme target with use_srq on, below kernel panic is noticed.[ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)[ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI..[ 566.393799] [ 566.393807] ? __die_body+0x1a/0x60[ 566.393823] ? die+0x38/0x60[ 566.393835] ? do_trap+0xe4/0x110[ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393881] ? do_error_trap+0x7c/0x120[ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393911] ? exc_divide_error+0x34/0x50[ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393939] ? asm_exc_divide_error+0x16/0x20[ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re][ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re][ 566.394057] ? srso_return_thunk+0x5/0x5f[ 566.394068] ? __init_swait_queue_head+0x4a/0x60[ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core][ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma][ 566.394174] ? lock_release+0x22c/0x3f0[ 566.394187] ? srso_return_thunk+0x5/0x5fPage size and shift info is set only for the user space SRQs.Set page size and page shift for kernel space SRQs also.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix implicit ODP hang on parent deregistrationFix the destroy_unused_implicit_child_mr() to prevent hanging duringparent deregistration as of below [1].Upon entering destroy_unused_implicit_child_mr(), the reference countfor the implicit MR parent is incremented using:refcount_inc_not_zero().A corresponding decrement must be performed iffree_implicit_child_mr_work() is not called.The code has been updated to properly manage the reference count thatwas incremented.[1]INFO: task python3:2157 blocked for more than 120 seconds.Not tainted 6.12.0-rc7+ #1633"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000Call Trace:__schedule+0x420/0xd30schedule+0x47/0x130__mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib]? __pfx_autoremove_wake_function+0x10/0x10ib_dereg_mr_user+0x5f/0x120 [ib_core]? lock_release+0xc6/0x280destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]uobj_destroy+0x3f/0x70 [ib_uverbs]ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]? lock_acquire+0xc1/0x2f0? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]? lock_release+0xc6/0x280ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70? kmem_cache_free+0x221/0x400do_syscall_64+0x6b/0x140entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f20f21f017bRSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017bRDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_upThe issue was caused by dput(upper) being called beforeovl_dentry_update_reval(), while upper->d_flags was stillaccessed in ovl_dentry_remote().Move dput(upper) after its last use to prevent use-after-free.BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix a WARN during dereg_mr for DM typeMemory regions (MR) of type DM (device memory) do not have an associatedumem.In the __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs() flow, the codeincorrectly takes the wrong branch, attempting to calldma_unmap_single() on a DMA address that is not mapped.This results in a WARN [1], as shown below.The issue is resolved by properly accounting for the DM type andensuring the correct branch is selected in mlx5_free_priv_descs().[1]WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_coreCPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:iommu_dma_unmap_page+0x79/0x90Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00RSP: 0018:ffffc90001913a10 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:? __warn+0x84/0x190? iommu_dma_unmap_page+0x79/0x90? report_bug+0xf8/0x1c0? handle_bug+0x55/0x90? exc_invalid_op+0x13/0x60? asm_exc_invalid_op+0x16/0x20? iommu_dma_unmap_page+0x79/0x90dma_unmap_page_attrs+0xe6/0x290mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]__mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]? _raw_spin_unlock_irq+0x24/0x40? wait_for_completion+0xfe/0x130? rdma_restrack_put+0x63/0xe0 [ib_core]ib_dereg_mr_user+0x5f/0x120 [ib_core]? lock_release+0xc6/0x280destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]uobj_destroy+0x3f/0x70 [ib_uverbs]ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]? lock_acquire+0xc1/0x2f0? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]? lock_release+0xc6/0x280ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]__x64_sys_ioctl+0x1b0/0xa70do_syscall_64+0x6b/0x140entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f537adaf17bCode: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 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 ed ac 0c 00 f7 d8 64 89 01 48RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17bRDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Add RCU read lock protection to perf_iterate_ctx()The perf_iterate_ctx() function performs RCU list traversal butcurrently lacks RCU read lock protection. This causes lockdep warningswhen running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y: WARNING: suspicious RCU usage kernel/events/core.c:8168 RCU-list traversed in non-reader section!! Call Trace: lockdep_rcu_suspicious ? perf_event_addr_filters_apply perf_iterate_ctx perf_event_exec begin_new_exec ? load_elf_phdrs load_elf_binary ? lock_acquire ? find_held_lock ? bprm_execve bprm_execve do_execveat_common.isra.0 __x64_sys_execve do_syscall_64 entry_SYSCALL_64_after_hwframeThis protection was previously present but was removed in commitbd2756811766 ("perf: Rewrite core context handling"). Add back thenecessary rcu_read_lock()/rcu_read_unlock() pair aroundperf_iterate_ctx() call in perf_event_exec().[ mingo: Use scoped_guard() as suggested by Peter ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix checksums set in idpf_rx_rsc()idpf_rx_rsc() uses skb_transport_offset(skb) while the transport headeris not set yet.This triggers the following warning for CONFIG_DEBUG_NET=y builds.DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))[ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth[ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697[ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)[ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261687] ? report_bug (lib/bug.c:?)[ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)[ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)[ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf[ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf[ 69.261712] __napi_poll (net/core/dev.c:7194)[ 69.261716] net_rx_action (net/core/dev.c:7265)[ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)[ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)[ 69.261726] handle_softirqs (kernel/softirq.c:561)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: ensure network headers are in skb linear partsyzbot found that ipvlan_process_v6_outbound() was assumingthe IPv6 network header isis present in skb->head [1]Add the needed pskb_network_may_pull() calls for bothIPv4 and IPv6 handlers.[1]BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix the recovery flow of the UMR QPThis patch addresses an issue in the recovery flow of the UMR QP,ensuring tasks do not get stuck, as highlighted by the call trace [1].During recovery, before transitioning the QP to the RESET state, thesoftware must wait for all outstanding WRs to complete.Failing to do so can cause the firmware to skip sending some flushedCQEs with errors and simply discard them upon the RESET, as per the IBspecification.This race condition can result in lost CQEs and tasks becoming stuck.To resolve this, the patch sends a final WR which serves only as abarrier before moving the QP state to RESET.Once a CQE is received for that final WR, it guarantees that nooutstanding WRs remain, making it safe to transition the QP to RESET andsubsequently back to RTS, restoring proper functionality.Note:For the barrier WR, we simply reuse the failed and ready WR.Since the QP is in an error state, it will only receiveIB_WC_WR_FLUSH_ERR. However, as it serves only as a barrier we don'tcare about its status.[1]INFO: task rdma_resource_l:1922 blocked for more than 120 seconds.Tainted: G W 6.12.0-rc7+ #1626"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:rdma_resource_l state:D stack:0 pid:1922 tgid:1922 ppid:1369 flags:0x00004004Call Trace:__schedule+0x420/0xd30schedule+0x47/0x130schedule_timeout+0x280/0x300? mark_held_locks+0x48/0x80? lockdep_hardirqs_on_prepare+0xe5/0x1a0wait_for_completion+0x75/0x130mlx5r_umr_post_send_wait+0x3c2/0x5b0 [mlx5_ib]? __pfx_mlx5r_umr_done+0x10/0x10 [mlx5_ib]mlx5r_umr_revoke_mr+0x93/0xc0 [mlx5_ib]__mlx5_ib_dereg_mr+0x299/0x520 [mlx5_ib]? _raw_spin_unlock_irq+0x24/0x40? wait_for_completion+0xfe/0x130? rdma_restrack_put+0x63/0xe0 [ib_core]ib_dereg_mr_user+0x5f/0x120 [ib_core]? lock_release+0xc6/0x280destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]uobj_destroy+0x3f/0x70 [ib_uverbs]ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]? __lock_acquire+0x64e/0x2080? mark_held_locks+0x48/0x80? find_held_lock+0x2d/0xa0? lock_acquire+0xc1/0x2f0? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]? __fget_files+0xc3/0x1b0ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]__x64_sys_ioctl+0x1b0/0xa70do_syscall_64+0x6b/0x140entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f99c918b17bRSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX: 00007f99c918b17bRDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI: 0000000000000003RBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09: 000000000000bd7eR10: 00007f99c94c1c70 R11: 0000000000000246 R12: 00007ffc766d0530R13: 000000000000001c R14: 0000000040246a80 R15: 0000000000000000
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:keys: Fix UAF in key_put()Once a key's reference count has been reduced to 0, the garbage collectorthread may destroy it at any time and so key_put() is not allowed to touchthe key after that point. The most key_put() is normally allowed to do isto touch key_gc_work as that's a static global variable.However, in an effort to speed up the reclamation of quota, this is nowdone in key_put() once the key's usage is reduced to 0 - but now the codeis looking at the key after the deadline, which is forbidden.Fix this by using a flag to indicate that a key can be gc'd now rather thanlooking at the key's refcount in the garbage collector.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNCActually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because onlyENETC PF can access PMa_SINGLE_STEP registers. And there will be a crashif VFs are used to test one-step timestamp, the crash log as follows.[ 129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0[ 129.287769] Call trace:[ 129.290219] enetc_port_mac_wr+0x30/0xec (P)[ 129.294504] enetc_start_xmit+0xda4/0xe74[ 129.298525] enetc_xmit+0x70/0xec[ 129.301848] dev_hard_start_xmit+0x98/0x118
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don't care about rec->counter * rec->counter overflow becauserec->time * rec->time overflow will likely happen earlier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix bad hist from corrupting named_triggers listThe following commands causes a crash: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=common_pid' > triggerBecause the following occurs:event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg;[..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)[..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- NEVER gets removed! } } } } [..] kfree(data); <<<-- frees item but it is still on listThe next time a hist with name is registered, it causes an u-a-f bug andthe kernel can crash.Move the code around such that if event_trigger_register() succeeds, thenext thing called is hist_trigger_enable() which adds it to the list.A bunch of actions is called if get_named_trigger_data() returns false.But that doesn't need to be called after event_trigger_register(), so itcan be moved up, allowing event_trigger_register() to be called justbefore hist_trigger_enable() keeping them together and allowing thefile->triggers to be properly populated.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:caif_virtio: fix wrong pointer check in cfv_probe()del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checkedfor NULL before calling it, not cfv->vdev. Also the current implementationis redundant because the pointer cfv->vdev is dereferenced before it ischecked for NULL.Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev beforecalling del_vqs().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: limit printed string from FW fileThere's no guarantee here that the file is always with aNUL-termination, so reading the string may read beyond theend of the TLV. If that's the last TLV in the file, it canperhaps even read beyond the end of the file buffer.Fix that by limiting the print format to the size of thebuffer we have.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject cooked mode if it is set along with other flagsIt is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVEflags simultaneously on the same monitor interface from the userspace. Thiscauses a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bitset because the monitor interface is in the cooked state and it takesprecedence over all other states. When the interface is then being deletedthe kernel calls WARN_ONCE() from check_sdata_in_driver() because of missingthat bit.Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along withother flags.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: regulatory: improve invalid hints checkingSyzbot keeps reporting an issue [1] that occurs when erroneous symbolssent from userspace get through into user_alpha2[] viaregulatory_hint_user() call. Such invalid regulatory hints should berejected.While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:reject invalid hints") looks to be enough to deter these very cases,there is a way to get around it due to 2 reasons.1) The way isalpha() works, symbols other than latin lower andupper letters may be used to determine a country/domain.For instance, greek letters will also be considered upper/lowerletters and for such characters isalpha() will return true as well.However, ISO-3166-1 alpha2 codes should only hold latincharacters.2) While processing a user regulatory request, betweenreg_process_hint_user() and regulatory_hint_user() there happens tobe a call to queue_regulatory_request() which modifies letters inrequest->alpha2[] with toupper(). This works fine for latin symbols,less so for weird letter characters from the second part of _ctype[].Syzbot triggers a warning in is_user_regdom_saved() by first sendingover an unexpected non-latin letter that gets malformed by toupper()into a character that ends up failing isalpha() check.Prevent this by enhancing is_an_alpha2() to ensure that incomingsymbols are latin letters and nothing else.[1] Syzbot report:------------[ cut here ]------------Unexpected user alpha2: A�WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516Modules linked in:CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events_power_efficient crda_timeout_workRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516...Call Trace: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix a flaw in existing endpoint checksSyzbot once again identified a flaw in usb endpoint checking, see [1].This time the issue stems from a commit authored by me (2eabb655a968("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).While using usb_find_common_endpoints() may usually be enough todiscard devices with wrong endpoints, in this case one needs morethan just finding and identifying the sufficient number of endpointsof correct types - one needs to check the endpoint's address as well.Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,switch the endpoint verification approach to usb_check_XXX_endpoints()instead to fix incomplete ep testing.[1] Syzbot report:usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...Call Trace: cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Flush the notify_hotplug_workWhen performing continuous unbind/bind operations on the USB driversavailable on the Renesas RZ/G2L SoC, a kernel crash with the message"Unable to handle kernel NULL pointer dereference at virtual address"may occur. This issue points to the usbhsc_notify_hotplug() function.Flush the delayed work to avoid its execution when driver resources areunavailable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Fix NULL pointer accessResources should be released only after all threads that utilize themhave been destroyed.This commit ensures that resources are not released prematurely by waitingfor the associated workqueue to complete before deallocating them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Fix potential memory corruption in child_cfs_rq_on_listchild_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,making the conversion invalid and potentially leading to memorycorruption. Depending on the relative positions of leaf_cfs_rq_list andthe task group (tg) pointer within the struct, this can cause a memoryfault or access garbage data.The issue arises in list_add_leaf_cfs_rq, where bothcfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the sameleaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the mainconditional in child_cfs_rq_on_list. This ensures that the container_ofoperation will convert a correct cfs_rq struct.This check is sufficient because only cfs_rqs on the same CPU are addedto the list, so verifying the 'prev' pointer against the current rq's listhead is enough.Fixes a potential memory corruption issue that due to current structlayout might not be manifesting as a crash but could lead to unpredictablebehavior when the layout changes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vlan: enforce underlying device typeCurrently, VLAN devices can be created on top of non-ethernet devices.Besides the fact that it doesn't make much sense, this also causes abug which leaks the address of a kernel function to usermode.When creating a VLAN device, we initialize GARP (garp_init_applicant)and MRP (mrp_init_applicant) for the underlying device.As part of the initialization process, we add the multicast address ofeach applicant to the underlying device, by calling dev_mc_add.__dev_mc_add uses dev->addr_len to determine the length of the newmulticast address.This causes an out-of-bounds read if dev->addr_len is greater than 6,since the multicast addresses provided by GARP and MRP are only 6bytes long.This behaviour can be reproduced using the following commands:ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev loip l set up dev gretestip link add link gretest name vlantest type vlan id 100Then, the following command will display the address of garp_pdu_rcv:ip maddr show | grep 01:80:c2:00:00:21Fix the bug by enforcing the type of the underlying device during VLANdevice initialization.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an errorDuring the initialization of ptp, hclge_ptp_get_cycle might return an errorand returned directly without unregister clock and free it. To avoid that,call hclge_ptp_destroy_clock to unregist and free clock ifhclge_ptp_get_cycle failed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:llc: do not use skb_get() before dev_queue_xmit()syzbot is able to crash hosts [1], using llc and devicesnot supporting IFF_TX_SKB_SHARING.In this case, e1000 driver calls eth_skb_pad(), whilethe skb is shared.Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.cNote that e1000 driver might have an issue with pktgen,because it does not clear IFF_TX_SKB_SHARING, this is anorthogonal change.We need to audit other skb_get() uses in net/llc.[1]kernel BUG at net/core/skbuff.c:2178 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178Call Trace: __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix ownership in __udp_gso_segmentIn __udp_gso_segment the skb destructor is removed before segmenting theskb but the socket reference is kept as-is. This is an issue if theoriginal skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50The above can happen following a sequence of events when usingOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes anOVS_ACTION_ATTR_OUTPUT action:1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed.2. The segments' data are copied and sent to userspace.3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path.4. If it later hits skb_orphan, we hit the bug.Fix this by also removing the reference to the socket in__udp_gso_segment.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()nvme_tcp_recv_pdu() doesn't check the validity of the header length.When header digests are enabled, a target might send a packet with aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folioCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages tobe offlined) add page poison checks in do_migrate_range in order to makeoffline hwpoisoned page possible by introducing isolate_lru_page andtry_to_unmap for hwpoisoned page. However folio lock must be held beforecalling try_to_unmap. Add it to fix this problem.Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: fix an API misues when rio_add_net() failsrio_add_net() calls device_register() and fails when device_register()fails. Thus, put_device() should be used rather than kfree(). Add"mport->net = NULL;" to avoid a use after free issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked. If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()Add check for the return value of mgmt_alloc_skb() inmgmt_device_connected() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()Add check for the return value of mgmt_alloc_skb() inmgmt_remote_name() to prevent null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_paramsNull pointer dereference issue could occur when pipe_ctx->plane_stateis null. The fix adds a check to ensure 'pipe_ctx->plane_state' is notnull before accessing. This prevents a null pointer dereference.Found by code review.(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: appleir: Fix potential NULL dereference at raw event handleSyzkaller reports a NULL pointer dereference issue in input_event().BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395Read of size 8 at addr 0000000000000028 by task syz-executor199/2949CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens due to the malformed report items sent by the emulated devicewhich results in a report, that has no fields, being added to the report list.Due to this appleir_input_configured() is never called, hidinput_connect()fails which results in the HID_CLAIMED_INPUT flag is not being set. However,it does not make appleir_probe() fail and lets the event callback to becalled without the associated input device.Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hookearly if the driver didn't claim any input_dev for some reason. Moreover,some other hid drivers accessing input_dev in their event callbacks do havesimilar checks, too.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctlIn the "pmcmd_ioctl" function, three memory objects allocated bykmalloc are initialized by "hcall_get_cpu_state", which are thencopied to user space. The initializer is indeed implemented in"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk ofinformation leakage due to uninitialized bytes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlockThere are multiple places from where the recovery work gets scheduledasynchronously. Also, there are multiple places where the caller waitssynchronously for the recovery to be completed. One such place is duringthe PM shutdown() callback.If the device is not alive during recovery_work, it will try to reset thedevice using pci_reset_function(). This function internally will take thedevice_lock() first before resetting the device. By this time, if the lockhas already been acquired, then recovery_work will get stalled whilewaiting for the lock. And if the lock was already acquired by the callerwhich waits for the recovery_work to be completed, it will lead todeadlock.This is what happened on the X1E80100 CRD device when the device diedbefore shutdown() callback. Driver core calls the driver's shutdown()callback while holding the device_lock() leading to deadlock.And this deadlock scenario can occur on other paths as well, like duringthe PM suspend() callback, where the driver core would hold thedevice_lock() before calling driver's suspend() callback. And if therecovery_work was already started, it could lead to deadlock. This is alsoobserved on the X1E80100 CRD.So to fix both issues, use pci_try_reset_function() in recovery_work. Thisfunction first checks for the availability of the device_lock() beforetrying to reset the device. If the lock is available, it will acquire itand reset the device. Otherwise, it will return -EAGAIN. If that happens,recovery_work will fail with the error message "Recovery failed" as notmuch could be done.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: cleanup mana struct after debugfs_remove()When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),mana_gd_suspend() and mana_gd_resume() are called. If during thismana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfspointer does not get reinitialized and ends up pointing to older,cleaned-up dentry.Further in the hibernation path, as part of power_down(), mana_gd_shutdown()is triggered. This call, unaware of the failures in resume, tries to cleanupthe already cleaned up mana_port_debugfs value and hits the following bug:[ 191.359296] mana 7870:00:00.0: Shutdown was called[ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 191.360584] #PF: supervisor write access in kernel mode[ 191.361125] #PF: error_code(0x0002) - not-present page[ 191.361727] PGD 1080ea067 P4D 0[ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI[ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2[ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 191.364124] RIP: 0010:down_write+0x19/0x50[ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d[ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246[ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000[ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098[ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001[ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000[ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020[ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000[ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0[ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 191.372906] Call Trace:[ 191.373262] [ 191.373621] ? show_regs+0x64/0x70[ 191.374040] ? __die+0x24/0x70[ 191.374468] ? page_fault_oops+0x290/0x5b0[ 191.374875] ? do_user_addr_fault+0x448/0x800[ 191.375357] ? exc_page_fault+0x7a/0x160[ 191.375971] ? asm_exc_page_fault+0x27/0x30[ 191.376416] ? down_write+0x19/0x50[ 191.376832] ? down_write+0x12/0x50[ 191.377232] simple_recursive_removal+0x4a/0x2a0[ 191.377679] ? __pfx_remove_one+0x10/0x10[ 191.378088] debugfs_remove+0x44/0x70[ 191.378530] mana_detach+0x17c/0x4f0[ 191.378950] ? __flush_work+0x1e2/0x3b0[ 191.379362] ? __cond_resched+0x1a/0x50[ 191.379787] mana_remove+0xf2/0x1a0[ 191.380193] mana_gd_shutdown+0x3b/0x70[ 191.380642] pci_device_shutdown+0x3a/0x80[ 191.381063] device_shutdown+0x13e/0x230[ 191.381480] kernel_power_off+0x35/0x80[ 191.381890] hibernate+0x3c6/0x470[ 191.382312] state_store+0xcb/0xd0[ 191.382734] kobj_attr_store+0x12/0x30[ 191.383211] sysfs_kf_write+0x3e/0x50[ 191.383640] kernfs_fop_write_iter+0x140/0x1d0[ 191.384106] vfs_write+0x271/0x440[ 191.384521] ksys_write+0x72/0xf0[ 191.384924] __x64_sys_write+0x19/0x20[ 191.385313] x64_sys_call+0x2b0/0x20b0[ 191.385736] do_syscall_64+0x79/0x150[ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240[ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0[ 191.387124] ? __pfx_lru_add+0x10/0x10[ 191.387515] ? queued_spin_unlock+0x9/0x10[ 191.387937] ? do_anonymous_page+0x33c/0xa00[ 191.388374] ? __handle_mm_fault+0xcf3/0x1210[ 191.388805] ? __count_memcg_events+0xbe/0x180[ 191.389235] ? handle_mm_fault+0xae/0x300[ 19---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acdirmax mount optionUser-provided mount parameter acdirmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acregmax mount optionUser-provided mount parameter acregmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free on hdcp_work[Why]A slab-use-after-free is reported when HDCP is destroyed but theproperty_validate_dwork queue is still running.[How]Cancel the delayed work when destroying workqueue.(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmdAfter the hci sync command releases l2cap_conn, the hci receive data workqueue references the released l2cap_conn when sending to the upper layer.Add hci dev lock to the hci receive data work queue to synchronize the two.[1]BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: hci1 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Bridge, fix the crash caused by LAG state checkWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event istriggered. Driver finds the lower devices (PFs) to flush all theoffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returnsfalse if one of PF is unloaded. In such case,mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead ofthe alive PF, and the flush is skipped.Besides, the bridge fdb entry's lastuse is updated in mlx5 bridgeevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can beignored in this case because the upper interface for bond is deleted,and the entry will never be aged because lastuse is never updated.To make things worse, as the entry is alive, mlx5 bridge workqueuekeeps sending that event, which is then handled by kernel bridgenotifier. It causes the following crash when accessing the passed bondnetdev which is already destroyed.To fix this issue, remove such checks. LAG state is already checked incommit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when addingbond to bridge"), driver still need to skip offload if LAG becomesinvalid state after initialization. Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: handle errors in mlx5_chains_create_table()In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()and mlx5_get_flow_namespace() must be checked to prevent NULL pointerdereferences. If either function fails, the function should log errormessage with mlx5_core_warn() and return error pointer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/hyperv: Fix address space leak when Hyper-V DRM device is removedWhen a Hyper-V DRM device is probed, the driver allocates MMIO space forthe vram, and maps it cacheable. If the device removed, or in the errorpath for device probing, the MMIO space is released but no unmap is done.Consequently the kernel address space for the mapping is leaked.Fix this by adding iounmap() calls in the device removal path, and in theerror path during device probing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched: address a potential NULL pointer dereference in the GRED scheduler.If kzalloc in gred_init returns a NULL pointer, the code follows theerror handling path, invoking gred_destroy. This, in turn, callsgred_offload, where memset could receive a NULL pointer as input,potentially leading to a kernel crash.When table->opt is NULL in gred_init(), gred_change_table_def()is not called yet, so it is not necessary to call ->ndo_setup_tc()in gred_offload().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes."Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: ignore non-functional sensor in HP 5MP CameraThe HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface thatis not actually implemented. Attempting to access this non-functionalsensor via iio_info causes system hangs as runtime PM tries to wake upan unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffffAdd this device to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()On the off chance that command stream passed from userspace viaioctl() call to radeon_vce_cs_parse() is weirdly crafted andfirst command to execute is to encode (case 0x03000001), the functionin question will attempt to call radeon_vce_cs_reloc() with sizeargument that has not been properly initialized. Specifically, 'size'will point to 'tmp' variable before the latter had a chance to beassigned any value.Play it safe and init 'tmp' with 0, thus ensuring thatradeon_vce_cs_reloc() will catch an early error in cases like these.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix an integer overflow in xp_create_and_assign_umem()Since the i and pool->chunk_size variables are of type 'u32',their product can wrap around and then be cast to 'u64'.This can lead to two different XDP buffers pointing to the samememory area.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ucan: fix out of bound read in strscpy() sourceCommit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")unintentionally introduced a one byte out of bound read on strscpy()'ssource argument (which is kind of ironic knowing that strscpy() is meantto be a more secure alternative :)).Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */When doing: strncpy(dest, src, len); dest[len] = '\0';strncpy() will read up to len bytes from src.On the other hand: strscpy(dest, src, len + 1);will read up to len + 1 bytes from src, that is to say, an out of boundread of one byte will occur on src if it is not NUL terminated. Notethat the src[len] byte is never copied, but strscpy() still needs toread it to check whether a truncation occurred or not.This exact pattern happened in ucan.The root cause is that the source is not NUL terminated. Instead ofdoing a copy in a local buffer, directly NUL terminate it as soon asusb_control_msg() returns. With this, the local firmware_str[] variablecan be removed.On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everythingwhen it fails.Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output incase it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in theerror path.Note that we can remove the fib6_nh_release() call in nh_create_ipv6()later in net-next.git.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix error code in chan_alloc_skb_cb()The chan_alloc_skb_cb() function is supposed to return error pointers onerror. Returning NULL will lead to a NULL dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: check that dummy regulator has been probed before using itDue to asynchronous driver probing there is a chance that the dummyregulator hasn't already been probed when first accessing it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup during bt pages loopDriver runs a for-loop when allocating bt pages and mapping them withbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bcAdd a cond_resched() to fix soft lockup during these loops. In order notto affect the allocation performance of normal-size buffer, set the loopcount of a 100GB MR as the threshold to call cond_resched().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pdr: Fix the potential deadlockWhen some client process A call pdr_add_lookup() to add the look up forthe service and does schedule locator work, later a process B got a newserver packet indicating locator is up and call pdr_locator_new_server()which eventually sets pdr->locator_init_complete to true which process Asees and takes list lock and queries domain list but it will timeout dueto deadlock as the response will queued to the same qmi->wq and it isordered workqueue and process B is not able to complete new serverrequest work due to deadlock on list lock.Fix it by removing the unnecessary list iteration as the list iterationis already being done inside locator work, so avoid it here and justcall schedule_work() here. Process A Process B process_scheduled_works()pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret);Timeout error log due to deadlock:" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110"Thanks to Bjorn and Johan for letting me know that this commit also fixesan audio regression when using the in-kernel pd-mapper as that makes iteasier to hit this race. [1]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Fix NULL pointer dereferenceWhen MPOA_cache_impos_rcvd() receives the msg, it can triggerNull Pointer Dereference Vulnerability if both entry andholding_time are NULL. Because there is only for the situationwhere entry is NULL and holding_time exists, it can be passedwhen both entry and holding_time are NULL. If these are NULL,the entry will be passd to eg_cache_put() as parameter andit is referenced by entry->use code in it.kasan log:[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0[ 3.326430] Call Trace:[ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0[ 3.327330] ? exc_general_protection+0x161/0x2a0[ 3.327662] ? asm_exc_general_protection+0x26/0x30[ 3.328214] ? vprintk_emit+0x15e/0x420[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10[ 3.329664] ? console_unlock+0x107/0x1d0[ 3.329946] ? __pfx_console_unlock+0x10/0x10[ 3.330283] ? do_syscall_64+0xa6/0x1a0[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10[ 3.331395] ? down_trylock+0x52/0x80[ 3.331703] ? vprintk_emit+0x15e/0x420[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10[ 3.332279] ? down_trylock+0x52/0x80[ 3.332527] ? _printk+0xbf/0x100[ 3.332762] ? __pfx__printk+0x10/0x10[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10[ 3.333614] msg_from_mpoad+0x1185/0x2750[ 3.333893] ? __build_skb_around+0x27b/0x3a0[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10[ 3.334501] ? __alloc_skb+0x1c0/0x310[ 3.334809] ? __pfx___alloc_skb+0x10/0x10[ 3.335283] ? _raw_spin_lock+0xe0/0xe0[ 3.335632] ? finish_wait+0x8d/0x1e0[ 3.335975] vcc_sendmsg+0x684/0xba0[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10[ 3.337056] ? fdget+0x176/0x3e0[ 3.337348] __sys_sendto+0x4a2/0x510[ 3.337663] ? __pfx___sys_sendto+0x10/0x10[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400[ 3.338364] ? sock_ioctl+0x1bb/0x5a0[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10[ 3.339727] ? selinux_file_ioctl+0xa4/0x260[ 3.340166] __x64_sys_sendto+0xe0/0x1c0[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140[ 3.340898] do_syscall_64+0xa6/0x1a0[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 3.341533] RIP: 0033:0x44a380[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00[ ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vimc: skip .s_stream() for stopped entitiesSyzbot reported [1] a warning prompted by a check in call_s_stream()that checks whether .s_stream() operation is warranted for unstartedor stopped subdevs.Add a simple fix in vimc_streamer_pipeline_terminate() ensuring thatentities skip a call to .s_stream() unless they have been previouslyproperly started.[1] Syzbot report:------------[ cut here ]------------WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460Modules linked in:CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0...Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2b85c01b19...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: fix narrowing conversion in acpi_nfit_ctlSyzkaller has reported a warning in to_nfit_bus_uuid(): "only secondarybus families can be translated". This warning is emited if the argumentis equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() firstverifies that a user-provided value call_pkg->nd_family of type u64 isnot equal to 0. Then the value is converted to int, and only after thatis compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalidargument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, whilethe lower 32 bits are zero.Furthermore, it is best to return EINVAL immediately upon seeing theinvalid user input. The WARNING is insufficient to prevent furtherundefined behavior based on other invalid user input.All checks of the input value should be applied to the original variablecall_pkg->nd_family.[iweiny: update commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet:fix NPE during rx_completeMissing usbnet_going_away Check in Critical Path.The usb_submit_urb function lacks a usbnet_going_awayvalidation, whereas __usbnet_queue_skb includes this check.This inconsistency creates a race condition where:A URB request may succeed, but the corresponding SKB datafails to be queued.Subsequent processes:(e.g., rx_complete -> defer_bh -> __skb_unlink(skb, list))attempt to access skb->next, triggering a NULL pointerdereference (Kernel Panic).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ibmveth: make veth_pool_store stop hangingv2:- Created a single error handling unlock and exit in veth_pool_store- Greatly expanded commit message with previous explanatory-only textSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,ibmveth_close and ibmveth_open, preventing multiple calls in a row tonapi_disable.Background: Two (or more) threads could call veth_pool_store throughwriting to /sys/devices/vio/30000002/pool*/*. You can do this easilywith a little shell script. This causes a hang.I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a newkernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: Prevent parser TCAM memory corruptionProtect the parser TCAM/SRAM memory, and the cached (shadow) SRAMinformation, from concurrent modifications.Both the TCAM and SRAM tables are indirectly accessed by configuringan index register that selects the row to read or write to. This meansthat operations must be atomic in order to, e.g., avoid spreadingwrites across multiple rows. Since the shadow SRAM array is used tofind free rows in the hardware table, it must also be protected inorder to avoid TOCTOU errors where multiple cores allocate the samerow.This issue was detected in a situation where `mvpp2_set_rx_mode()` ranconcurrently on two CPUs. In this particular case theMVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing theclassifier unit to drop all incoming unicast - indicated by the`rx_classifier_drops` counter.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: add mutual exclusion in proc_sctp_do_udp_port()We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()or risk a crash as syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: imx-card: Add NULL check in imx_card_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,imx_card_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spufs: fix gang directory lifetimesprior to "[POWERPC] spufs: Fix gang destroy leaks" we used to havea problem with gang lifetimes - creation of a gang returns openedgang directory, which normally gets removed when that gets closed,but if somebody has created a context belonging to that gang andkept it alive until the gang got closed, removal failed and weended up with a leak.Unfortunately, it had been fixed the wrong way. Dentry of gangdirectory was no longer pinned, and rmdir on close was gone.One problem was that failure of open kept calling simple_rmdir()as cleanup, which meant an unbalanced dput(). Another bug wasin the success case - gang creation incremented link count onroot directory, but that was no longer undone when gang gotdestroyed.Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsemof gang directory inode. * having it set to 1 at creation time, droppedin both spufs_dir_close() and spufs_gang_close() and bumpedin spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gangdirectory out when counter reaches zero.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Allocate vfinfo size for VF GUIDs when supportedCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")added support for getting VF port and node GUIDs in netlink ifinfomessages, but their size was not taken into consideration in thefunction that allocates the netlink message, causing the followingwarning when a netlink message is filled with many VF port and nodeGUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too longKernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "smb: client: fix TCP timers deadlock after rmmod"This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock afterrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which ismentioned as CVE-2024-54680, but is actually did not fix anything;The issue can be reproduced on top of it. [0]Also, it reverted the change by commit ef7134c7fc48 ("smb: client:Fix use-after-free of network namespace.") and introduced a realissue by reviving the kernel TCP socket.When a reconnect happens for a CIFS connection, the socket statetransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()in tcp_close() stops all timers for the socket.If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.Usually, FIN can be retransmitted by the peer, but if the peer abortsthe connection, the issue comes into reality.I warned about this privately by pointing out the exact report [1],but the bogus fix was finally merged.So, we should not stop the timers to finally kill the connection onour side in that case, meaning we must not use a kernel socket forTCP whose sk->sk_net_refcnt is 0.The kernel socket does not have a reference to its netns to make itpossible to tear down netns without cleaning up every resource in it.For example, tunnel devices use a UDP socket internally, but we candestroy netns without removing such devices and let it completeduring exit. Otherwise, netns would be leaked when the last applicationdied.However, this is problematic for TCP sockets because TCP has timers toclose the connection gracefully even after the socket is close()d. Thelifetime of the socket and its netns is different from the lifetime ofthe underlying connection.If the socket user does not maintain the netns lifetime, the timer couldbe fired after the socket is close()d and its netns is freed up, resultingin use-after-free.Actually, we have seen so many similar issues and converted such socketsto have a reference to netns.That's why I converted the CIFS client socket to have a reference tonetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scopeof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and rightfix**.Regarding the LOCKDEP issue, we can prevent the module unload bybumping the module refcount when switching the LOCKDDEP key insock_lock_init_class_and_name(). [2]For a while, let's revert the bogus fix.Note that now we can use sk_net_refcnt_upgrade() for the socketconversion, but I'll do so later separately to make backport easy.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpointIf vhost_scsi_set_endpoint is called multiple times without avhost_scsi_clear_endpoint between them, we can hit multiple bugsfound by Haoran Zhang:1. Use-after-free when no tpgs are found:This fixes a use after free that occurs when vhost_scsi_set_endpoint iscalled more than once and calls after the first call do not find anytpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first findstpgs to add to the vs_tpg array match=true, so we will do:vhost_vq_set_backend(vq, vs_tpg);...kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If vhost_scsi_set_endpoint is called again and no tpgs are foundmatch=false so we skip the vhost_vq_set_backend call leaving thepointer to the vs_tpg we then free via:kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If a scsi request is then sent we do:vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backendwhich sees the vs_tpg we just did a kfree on.2. Tpg dir removal hang:This patch fixes an issue where we cannot remove a LIO/target layertpg (and structs above it like the target) dir due to the refcountdropping to -1.The problem is that if vhost_scsi_set_endpoint detects a tpg is alreadyin the vs->vs_tpg array or if the tpg has been removed sotarget_depend_item fails, the undepend goto handler will dotarget_undepend_item on all tpgs in the vs_tpg array dropping theirrefcount to 0. At this time vs_tpg contains both the tpgs we have addedin the current vhost_scsi_set_endpoint call as well as tpgs we added inprevious calls which are also in vs->vs_tpg.Later, when vhost_scsi_clear_endpoint runs it will dotarget_undepend_item on all the tpgs in the vs->vs_tpg which will droptheir refcount to -1. Userspace will then not be able to remove the tpgand will hang when it tries to do rmdir on the tpg dir.3. Tpg leak:This fixes a bug where we can leak tpgs and cause them to beun-removable because the target name is overwritten whenvhost_scsi_set_endpoint is called multiple times but with differenttarget names.The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setupa vhost-scsi device to target/tpg mapping, then callsVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs wehaven't seen before (target1 has tpg1 but target2 has tpg2). When thishappens we don't teardown the old target tpg mapping and just overwritethe target name and the vs->vs_tpg array. Later when we dovhost_scsi_clear_endpoint, we are passed in either target1 or target2'sname and we will only match that target's tpgs when we loop over thevs->vs_tpg. We will then return from the function without doingtarget_undepend_item on the tpgs.Because of all these bugs, it looks like being able to callvhost_scsi_set_endpoint multiple times was never supported. The majoruser, QEMU, already has checks to prevent this use case. So to fix theissues, this patch prevents vhost_scsi_set_endpoint from being calledif it's already successfully added tpgs. To add, remove or change thetpg config or target name, you must do a vhost_scsi_clear_endpointfirst.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flowWhen cur_qp isn't NULL, in order to avoid fetching the QP fromthe radix tree again we check if the next cqe QP is identical tothe one we already have.The bug however is that we are checking if the QP is identical bychecking the QP number inside the CQE against the QP number inside themlx5_ib_qp, but that's wrong since the QP number from the CQE is fromFW so it should be matched against mlx5_core_qp which is our FW QPnumber.Otherwise we could use the wrong QP when handling a CQE which couldcause the kernel trace below.This issue is mainly noticeable over QPs 0 & 1, since for now they arethe only QPs in our driver whereas the QP number inside mlx5_ib_qpdoesn't match the QP number inside mlx5_core_qp.BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()If track_pfn_copy() fails, we already added the dst VMA to the mapletree. As fork() fails, we'll cleanup the maple tree, and stumble overthe dst VMA for which we neither performed any reservation nor copiedany page tables.Consequently untrack_pfn() will see VM_PAT and try obtaining thePAT information from the page table -- which fails because the pagetable was not copied.The easiest fix would be to simply clear the VM_PAT flag of the dst VMAif track_pfn_copy() fails. However, the whole thing is about "simply"clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()and performed a reservation, but copying the page tables fails, we'llsimply clear the VM_PAT flag, not properly undoing the reservation ...which is also wrong.So let's fix it properly: set the VM_PAT flag only if the reservationsucceeded (leaving it clear initially), and undo the reservation ifanything goes wrong while copying the page tables: clearing the VM_PATflag after undoing the reservation.Note that any copied page table entries will get zapped when the VMA willget removed later, after copy_page_range() succeeded; as VM_PAT is not setthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will behappy. Note that leaving these page tables in place without a reservationis not a problem, as we are aborting fork(); this process will never run.A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")... and instead of undoing the reservation we simply cleared the VM_PAT flag.Keep the documentation of these functions in include/linux/pgtable.h,one place is more than sufficient -- we should clean that up for the otherfunctions like track_pfn_remap/untrack_pfn separately.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: check xdp prog when set bond modeFollowing operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1When delete the namespace, dev_xdp_uninstall() is called to remove xdpprogram on bond dev, and bond_xdp_set() will check the bond mode. If bondmode is changed after attaching xdp program, the warning may occur.Some bond modes (broadcast, etc.) do not support native xdp. Set bond modewith xdp program attached is not good. Add check for xdp program when setbond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Remove broken autobindBinding AX25 socket by using the autobind feature leads to memory leaksin ax25_connect() and also refcount leaks in ax25_release(). Memoryleak was detected with kmemleak:================================================================unreferenced object 0xffff8880253cd680 (size 96):backtrace:__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)kmemdup_noprof (mm/util.c:136)ax25_rt_autobind (net/ax25/ax25_route.c:428)ax25_connect (net/ax25/af_ax25.c:1282)__sys_connect_file (net/socket.c:2045)__sys_connect (net/socket.c:2064)__x64_sys_connect (net/socket.c:2067)do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)================================================================When socket is bound, refcounts must be incremented the way it is donein ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case ofautobind, the refcounts are not incremented.This bug leads to the following issue reported by Syzkaller:================================================================ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de------------[ cut here ]------------refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31Modules linked in:CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31...Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Considering the issues above and the comments left in the code that say:"check if we can remove this feature. It is broken."; "autobinding in thismay or may not work"; - it is better to completely remove this feature thanto fix it because it is broken and leads to various kinds of memory bugs.Now calling connect() without first binding socket will result in anerror (-EINVAL). Userspace software that relies on the autobind featuremight get broken. However, this feature does not seem widely used withthis specific driver as it was not reliable at any point of time, and itis already broken anyway. E.g. ax25-tools and ax25-apps packages forpopular distributions do not use the autobind feature for AF_AX25.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1,raid10: don't ignore IO flagsIf blk-wbt is enabled by default, it's found that raid write performanceis quite bad because all IO are throttled by wbt of underlying disks,due to flag REQ_IDLE is ignored. And turns out this behaviour exist sinceblk-wbt is introduced.Other than REQ_IDLE, other flags should not be ignored as well, forexample REQ_META can be set for filesystems, clearing it can cause priorityreverse problems; And REQ_NOWAIT should not be cleared as well, becauseio will wait instead of failing directly in underlying disks.Fix those problems by keep IO flags from master bio.Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error pathIf a shared IRQ is used by the driver due to platform limitation, then theIRQ affinity hint is set right after the allocation of IRQ vectors inath11k_pci_alloc_msi(). This does no harm unless one of the functionsrequesting the IRQ fails and attempt to free the IRQ. This results in thebelow warning:WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29cCall trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbcThe warning is due to not clearing the affinity hint before freeing theIRQs.So to fix this issue, clear the IRQ affinity hint before callingath11k_pcic_free_irq() in the error path. The affinity will be cleared onceagain further down the error path due to code organization, but that doesno harm.Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: int340x: Add NULL check for adevNot all devices have an ACPI companion fwnode, so adev might be NULL.This is similar to the commit cd2fd6eab480("platform/x86: int3472: Check for adev == NULL").Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in int3402_thermal_probe().Note, under the same directory, int3400_thermal_probe() has such acheck.[ rjw: Subject edit, added Fixes: ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq errorAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQshave been released.However, some requested IRQs remain unreleased, so there are still/proc/irq/* entries remaining, and this results in WARN() with thefollowing message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19cTo solve this issue, set the number of remaining IRQs to test->num_irqs,and release IRQs in advance by calling pci_endpoint_test_release_irq().[kwilczynski: commit log]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: detect and prevent references to a freed transport in sendmsgsctp_sendmsg() re-uses associations and transports when possible bydoing a lookup based on the socket endpoint and the message destinationaddress, and then sctp_sendmsg_to_asoc() sets the selected transport inall the message chunks to be sent.There's a possible race condition if another thread triggers the removalof that selected transport, for instance, by explicitly unbinding anaddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks havebeen set up and before the message is sent. This can happen if the sendbuffer is full, during the period when the sender thread temporarilyreleases the socket lock in sctp_wait_for_sndbuf().This causes the access to the transport data insctp_outq_select_transport(), when the association outqueue is flushed,to result in a use-after-free read.This change avoids this scenario by having sctp_transport_free() signalthe freeing of the transport, tagging it as "dead". In order to do this,the patch restores the "dead" bit in struct sctp_transport, which wasremoved incommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").Then, in the scenario where the sender thread has released the socketlock in sctp_wait_for_sndbuf(), the bit is checked again afterre-acquiring the socket lock to detect the deletion. This is done whileholding a reference to the transport to prevent it from being freed inthe process.If the transport was deleted while the socket lock was relinquished,sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry thesend.The bug was found by a private syzbot instance (see the error report [1]and the C reproducer that triggers it [2]).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.When I ran the repro [0] and waited a few seconds, I observed twoLOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables ruleAt step 3), the CIFS module calls sock_release() for the underlyingTCP socket, and it returns quickly. However, the socket remains inFIN_WAIT_1 because incoming FIN packets are dropped.At this point, the module's refcnt is 0 while the socket is stillalive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0This highlights a discrepancy between the lifetime of the CIFS moduleand the underlying TCP socket. Even after CIFS calls sock_release()and it returns, the TCP socket does not die immediately in order toclose the connection gracefully.While this is generally fine, it causes an issue with LOCKDEP becauseCIFS assigns a different lock class to the TCP socket's sk->sk_lockusing sock_lock_init_class_and_name().Once an incoming packet is processed for the socket or a timer fires,sk->sk_lock is acquired.Then, LOCKDEP checks the lock context in check_wait_context(), wherehlock_class() is called to retrieve the lock class. However, sincethe module has already been unloaded, hlock_class() logs a warningand returns NULL, triggering the null-ptr-deref.If LOCKDEP is enabled, we must ensure that a module callingsock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloadedwhile such a socket is still alive to prevent this issue.Let's hold the module reference in sock_lock_init_class_and_name()and release it when the socket is freed in sk_prot_free().Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()that calls sock_lock_init_class_and_name() for a listening socket,which clones a socket by sk_clone_lock() without GFP_ZERO.[0]:CIFS_SERVER="10.0.0.137"CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"DEV="enp0s3"CRED="/root/WindowsCredential.txt"MNT=$(mktemp -d /tmp/XXXXXX)mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1iptables -A INPUT -s ${CIFS_SERVER} -j DROPfor i in $(seq 10);do umount ${MNT} rmmod cifs sleep 1donerm -r ${MNT}iptables -D INPUT -s ${CIFS_SERVER} -j DROP[1]:DEBUG_LOCKS_WARN_ON(1)WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)...Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)...BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36Tainted: [W]=WARNHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__lock_acquire (kernel/---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: ene-kb3930: Fix a potential NULL pointer dereferenceThe off_gpios could be NULL. Add missing check in the kb3930_probe().This is similar to the issue fixed in commit b1ba8bcb2d1f("backlight: hx8357: Fix potential NULL pointer dereference").This was detected by our static analysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: Add NULL pointer check in i3c_master_queue_ibi()The I3C master driver may receive an IBI from a target device that has notbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`to queue an IBI work task, leading to "Unable to handle kernel read fromunreadable memory" and resulting in a kernel panic.Typical IBI handling flow:1. The I3C master scans target devices and probes their respective drivers.2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`.3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver's IBI handler task.However, since target device events are asynchronous to the I3C probesequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,leading to a kernel panic.Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessingan uninitialized `dev->ibi`, ensuring stability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()soc_dev_attr->revision could be NULL, thus,a pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: do not start chip while suspendedChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() canlead to a spurious tpm_chip_start() call:[35985.503771] i2c i2c-1: Transfer while suspended[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810[35985.503802] Modules linked in:[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f[35985.503814] Tainted: [W]=WARN[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0[35985.503855] Call Trace:[35985.503859] [35985.503863] ? __warn+0xd4/0x260[35985.503868] ? __i2c_transfer+0xbe/0x810[35985.503874] ? report_bug+0xf3/0x210[35985.503882] ? handle_bug+0x63/0xb0[35985.503887] ? exc_invalid_op+0x16/0x50[35985.503892] ? asm_exc_invalid_op+0x16/0x20[35985.503904] ? __i2c_transfer+0xbe/0x810[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0[35985.503920] tpm_cr50_i2c_read+0x8e/0x120[35985.503928] tpm_cr50_request_locality+0x75/0x170[35985.503935] tpm_chip_start+0x116/0x160[35985.503942] tpm_try_get_ops+0x57/0x90[35985.503948] tpm_find_get_ops+0x26/0xd0[35985.503955] tpm_get_random+0x2d/0x80Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unlessTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL insuch a failure case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix off-by-one error in do_splitSyzkaller detected a use-after-free issue in ext4_insert_dentry that wascaused by out-of-bounds access due to incorrect splitting in do_split.BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement.for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++;}'i' in this case could go down to -1, in which case sum of active entrieswouldn't exceed half the block size, but previous behaviour would also dosplit in half if sum would exceed at the very last block, which in case ofhaving too many long name files in a single block could lead toout-of-bounds access and following use-after-free.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Fix race between unprepare and queue_bufA client driver may use mhi_unprepare_from_transfer() to quiesceincoming data during the client driver's tear down. The client drivermight also be processing data at the same time, resulting in a call tomhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runsafter mhi_unprepare_from_transfer() has torn down the channel, a panicwill occur due to an invalid dereference leading to a page fault.This occurs because mhi_gen_tre() does not verify the channel stateafter locking it. Fix this by having mhi_gen_tre() confirm the channelstate is valid, or return error to avoid accessing deinitialized data.[mani: added stable tag]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Fix accessing freed irq affinity_hintIn stmmac_request_irq_multi_msi(), a pointer to the stack variablecpu_mask is passed to irq_set_affinity_hint(). This value is stored inirq_desc->affinity_hint, but once stmmac_request_irq_multi_msi()returns, the pointer becomes dangling.The affinity_hint is exposed via procfs with S_IRUGO permissions,allowing any unprivileged process to read it. Accessing this stalepointer can lead to:- a kernel oops or panic if the referenced memory has been released and unmapped, or- leakage of kernel data into userspace if the memory is re-used for other purposes.All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) areaffected.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: refactor hfi packet parsing logicwords_count denotes the number of words in total payload, while datapoints to payload of various property within it. When words_countreaches last word, data can access memory beyond the total payload. Thiscan lead to OOB access. With this patch, the utility api for handlingindividual properties now returns the size of data consumed. Accordinglyremaining bytes are calculated before parsing the payload, therebyeliminates the OOB access possibilities.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: add check to avoid out of bound accessThere is a possibility that init_codecs is invoked multiple times duringmanipulated payload from video firmware. In such case, if codecs_countcan get incremented to value more than MAX_CODEC_NUM, there can be OOBaccess. Reset the count so that it always starts from beginning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add check to handle incorrect queue sizeqsize represents size of shared queued between driver and videofirmware. Firmware can modify this value to an invalid large value. Insuch situation, empty_space will be bigger than the space actuallyavailable. Since new_wr_idx is not checked, so the following code willresult in an OOB write....qsize = qhdr->q_sizeif (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx)....if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB writeAdd check to ensure qsize is within the allocated size whilereading and writing packets into the queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add a check to handle OOB in sfr regionsfr->buf_size is in shared memory and can be modified by malicious user.OOB write is possible when the size is made higher than actual sfr databuffer. Cap the size to allocated size for such cases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initializationOn Mediatek devices with a system companion processor (SCP) the mtk_scpstructure has to be removed explicitly to avoid a resource leak.Free the structure in case the allocation of the firmware structure failsduring the firmware initialization.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t typeThe access to the PCI config space via pci_ops::read and pci_ops::write isa low-level hardware access. The functions can be accessed with disabledinterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for thispurpose.A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot beacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed inthe same context as the pci_lock.Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used withinterrupts disabled.This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90[bigeasy: reword commit message]Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log][bhelgaas: add back report info fromhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: don't propagate flags on openWith the device instance lock, there is now a possibility of a deadlock:[ 1.211455] ============================================[ 1.211571] WARNING: possible recursive locking detected[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted[ 1.211823] --------------------------------------------[ 1.211936] ip/184 is trying to acquire lock:[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0[ 1.212207][ 1.212207] but task is already holding lock:[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.212487][ 1.212487] other info that might help us debug this:[ 1.212626] Possible unsafe locking scenario:[ 1.212626][ 1.212751] CPU0[ 1.212815] ----[ 1.212871] lock(&dev->lock);[ 1.212944] lock(&dev->lock);[ 1.213016][ 1.213016] *** DEADLOCK ***[ 1.213016][ 1.213143] May be due to missing lock nesting notation[ 1.213143][ 1.213294] 3 locks held by ip/184:[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.213895][ 1.213895] stack backtrace:[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014[ 1.213994] Call Trace:[ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0[ 1.214000] print_deadlock_bug+0x28b/0x2a0[ 1.214020] lock_acquire+0xea/0x2a0[ 1.214027] __mutex_lock+0xbf/0xd40[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev[ 1.214042] __dev_open+0x145/0x270[ 1.214046] __dev_change_flags+0xb0/0x1e0[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0[ 1.214058] notifier_call_chain+0x78/0x120[ 1.214062] netif_open+0x6d/0x90[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0[ 1.214066] bond_enslave+0x64c/0x1230[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0[ 1.214077] do_setlink+0x516/0x13b0[ 1.214094] rtnl_newlink+0xaba/0xb80[ 1.214132] rtnetlink_rcv_msg+0x440/0x490[ 1.214144] netlink_rcv_skb+0xeb/0x120[ 1.214150] netlink_unicast+0x1f9/0x320[ 1.214153] netlink_sendmsg+0x346/0x3f0[ 1.214157] __sock_sendmsg+0x86/0xb0[ 1.214160] ____sys_sendmsg+0x1c8/0x220[ 1.214164] ___sys_sendmsg+0x28f/0x2d0[ 1.214179] __x64_sys_sendmsg+0xef/0x140[ 1.214184] do_syscall_64+0xec/0x1d0[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 1.214191] RIP: 0033:0x7f2d1b4a7e56Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down)When we enslave the lower device (netdevsim0) which has a vlan, wepropagate vlan's allmuti/promisc flags during ndo_open. This causes(re)locking on of the real_dev.Propagate allmulti/promisc on flags change, not on the open. Thereis a slight semantics change that vlans that are down now propagatethe flags, but this seems unlikely to result in the real issues.Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_groupCurrently, mtk_iommu calls during probe iommu_device_register beforethe hw_list from driver data is initialized. Since iommu probing issuefix, it leads to NULL pointer dereference in mtk_iommu_device_group whenhw_list is accessed with list_first_entry (not null safe).So, change the call order to ensure iommu_device_register is calledafter the driver data are initialized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in decryption with multichannelAfter commit f7025d861694 ("smb: client: allocate crypto only forprimary server") and commit b0abcd65ec54 ("smb: client: fix UAF inasync decryption"), the channels started reusing AEAD TFM from primarychannel to perform synchronous decryption, but that can't done asthere could be multiple cifsd threads (one per channel) simultaneouslyaccessing it to perform decryption.This fixes the following KASAN splat when running fstest generic/249with 'vers=3.1.1,multichannel,max_channels=4,seal' against WindowsServer 2022:BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110Read of size 8 at addr ffff8881046c18a0 by task cifsd/986CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/huc: Fix fence not released on early probe errorsHuC delayed loading fence, introduced with commit 27536e03271da("drm/i915/huc: track delayed HuC load with a fence"), is registered withobject tracker early on driver probe but unregistered only from driverremove, which is not called on early probe errors. Since its memory isallocated under devres, then released anyway, it may happen to beallocated again to the fence and reused on future driver probes, resultingin kernel warnings that taint the kernel:<4> [309.731371] ------------[ cut here ]------------<3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]<4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0...<4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1...<4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0...<4> [309.731728] Call Trace:<4> [309.731730] ...<4> [309.731949] __debug_object_init+0x17b/0x1c0<4> [309.731957] debug_object_init+0x34/0x50<4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915]<4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915]<4> [309.732468] intel_uc_init_early+0x61/0x680 [i915]<4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915]<4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915]<4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915]<4> [309.733075] i915_pci_probe+0xe6/0x220 [i915]<4> [309.733198] local_pci_probe+0x44/0xb0<4> [309.733203] pci_device_probe+0xf4/0x270<4> [309.733209] really_probe+0xee/0x3c0<4> [309.733215] __driver_probe_device+0x8c/0x180<4> [309.733219] driver_probe_device+0x24/0xd0<4> [309.733223] __driver_attach+0x10f/0x220<4> [309.733230] bus_for_each_dev+0x7d/0xe0<4> [309.733236] driver_attach+0x1e/0x30<4> [309.733239] bus_add_driver+0x151/0x290<4> [309.733244] driver_register+0x5e/0x130<4> [309.733247] __pci_register_driver+0x7d/0x90<4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915]<4> [309.733413] i915_init+0x34/0x120 [i915]<4> [309.733655] do_one_initcall+0x62/0x3f0<4> [309.733667] do_init_module+0x97/0x2a0<4> [309.733671] load_module+0x25ff/0x2890<4> [309.733688] init_module_from_file+0x97/0xe0<4> [309.733701] idempotent_init_module+0x118/0x330<4> [309.733711] __x64_sys_finit_module+0x77/0x100<4> [309.733715] x64_sys_call+0x1f37/0x2650<4> [309.733719] do_syscall_64+0x91/0x180<4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e<4> [309.733792] ...<4> [309.733806] ---[ end trace 0000000000000000 ]---That scenario is most easily reproducible withigt@i915_module_load@reload-with-fault-injection.Fix the issue by moving the cleanup step to driver release path.(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: explicitly disallow disconnectsyzbot discovered that it can disconnect a TLS socket and thenrun into all sort of unexpected corner cases. I have a vaguerecollection of Eric pointing this out to us a long time ago.Supporting disconnect is really hard, for one thing if offloadis enabled we'd need to wait for all packets to be _acked_.Disconnect is not commonly used, disallow it.The immediate problem syzbot run into is the warning in the strp,but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix memory leak in tipc_link_xmitIn case the backlog transmit queue for system-importance messages is overloaded,tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads tomemory leak and failure when a skb is allocated.This commit fixes this issue by purging the skb list before tipc_link_xmit()returns.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ublk: fix handling recovery & reissue in ublk_abort_queue()Commit 8284066946e6 ("ublk: grab request reference when the request is handledby userspace") doesn't grab request reference in case of recovery reissue.Then the request can be requeued & re-dispatch & failed when cancelinguring command.If it is one zc request, the request can be freed before io_uringreturns the zc buffer back, then cause kernel panic:[ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8[ 126.773657] #PF: supervisor read access in kernel mode[ 126.774052] #PF: error_code(0x0000) - not-present page[ 126.774455] PGD 0 P4D 0[ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI[ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full)[ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014[ 126.776275] Workqueue: iou_exit io_ring_exit_work[ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv]Fixes it by always grabbing request reference for aborting the request.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix an out-of-bounds shift when invalidating TLBWhen the size of the range invalidated is larger thanrounddown_pow_of_two(ULONG_MAX),The function macro roundup_pow_of_two(length) will hit an out-of-boundsshift [1].Use a full TLB invalidation for such cases.v2:- Use a define for the range size limit over which we use a full TLB invalidation. (Lucas)- Use a better calculation of the limit.[1]:[ 39.202421] ------------[ cut here ]------------[ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13[ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int'[ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10[ 39.202690] Tainted: [U]=USER[ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023[ 39.202691] Call Trace:[ 39.202692] [ 39.202695] dump_stack_lvl+0x6e/0xa0[ 39.202699] ubsan_epilogue+0x5/0x30[ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6[ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe][ 39.202800] ? find_held_lock+0x2b/0x80[ 39.202803] ? mark_held_locks+0x40/0x70[ 39.202806] xe_svm_invalidate+0x459/0x700 [xe][ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm][ 39.202900] __mmu_notifier_release+0x1f5/0x270[ 39.202905] exit_mmap+0x40e/0x450[ 39.202912] __mmput+0x45/0x110[ 39.202914] exit_mm+0xc5/0x130[ 39.202916] do_exit+0x21c/0x500[ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190[ 39.202920] do_group_exit+0x36/0xa0[ 39.202922] get_signal+0x8f8/0x900[ 39.202926] arch_do_signal_or_restart+0x35/0x100[ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290[ 39.202932] do_syscall_64+0xa1/0x180[ 39.202934] ? do_user_addr_fault+0x59f/0x8a0[ 39.202937] ? lock_release+0xd2/0x2a0[ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0[ 39.202942] ? trace_hardirqs_off+0x4b/0xc0[ 39.202944] ? clear_bhb_loop+0x25/0x80[ 39.202946] ? clear_bhb_loop+0x25/0x80[ 39.202947] ? clear_bhb_loop+0x25/0x80[ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 39.202952] RIP: 0033:0x7fa945e543e1[ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7.[ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293[ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3[ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff[ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0[ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000[ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000[ 39.202970] [ 39.202970] ---[ end trace ]---(cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imagination: take paired job referenceFor paired jobs, have the fragment job take a reference on thegeometry job, so that the geometry job cannot be freed untilthe fragment job has finished with it.The geometry job structure is accessed when the fragment job is beingprepared by the GPU scheduler. Taking the reference prevents thegeometry job being freed until the fragment job no longer requires it.Fixes a use after free bug detected by KASAN:[ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr][ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imagination: fix firmware memory leaksFree the memory used to hold the results of firmware image processingwhen the module is unloaded.Fix the related issue of the same memory being leaked if processingof the firmware image fails during module load.Ensure all firmware GEM objects are destroyed if firmware imageprocessing fails.Fixes memory leaks on powervr module unload detected by Kmemleak:unreferenced object 0xffff000042e20000 (size 94208): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr]unreferenced object 0xffff000042d20000 (size 20480): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix ttm_bo_delayed_delete oopsFix an oops in ttm_bo_delayed_delete which results from dererencing adangling pointer:Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMPCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024Workqueue: ttm ttm_bo_delayed_delete [ttm]RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8bRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6bR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383ccFS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is:- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo.- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo.- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete.- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.Fix this by moving the drm_prime_gem_destroy call fromnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it willbe run after ttm_bo_delayed_delete.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm/smu11: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.(cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Fix workqueue crash in cma_netevent_work_handlerstruct rdma_cm_id has member "struct work_struct net_work"that is reused for enqueuing cma_netevent_work_handler()sonto cma_wq.Below crash[1] can occur if more than one call tocma_netevent_callback() occurs in quick succession,which further enqueues cma_netevent_work_handler()s for thesame rdma_cm_id, overwriting any previously queued work-item(s)that was just scheduled to run i.e. there is no guaranteethe queued work item may run between two successive callsto cma_netevent_callback() and the 2nd INIT_WORK would overwritethe 1st work item (for the same rdma_cm_id), despite grabbingid_table_lock during enqueue.Also drgn analysis [2] indicates the work item was likely overwritten.Fix this by moving the INIT_WORK() to __rdma_create_id(),so that it doesn't race with any existing queue_work() orits worker thread.[1] Trimmed crash stack:=============================================BUG: kernel NULL pointer dereference, address: 0000000000000008kworker/u256:6 ... 6.12.0-0...Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)RIP: 0010:process_one_work+0xba/0x31aCall Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30=============================================[2] drgn crash analysis:>>> trace = prog.crashed_thread().stack_trace()>>> trace(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)(1) __crash_kexec (kernel/crash_core.c:122:4)(2) panic (kernel/panic.c:399:3)(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)...(8) process_one_work (kernel/workqueue.c:3168:2)(9) process_scheduled_works (kernel/workqueue.c:3310:3)(10) worker_thread (kernel/workqueue.c:3391:4)(11) kthread (kernel/kthread.c:389:9)Line workqueue.c:3168 for this kernel version is in process_one_work():3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);>>> trace[8]["work"]*(struct work_struct *)0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,}Suspicion is that pwq is NULL:>>> trace[8]["pwq"](struct pool_workqueue *)
In process_one_work(), pwq is assigned from:struct pool_workqueue *pwq = get_work_pwq(work);and get_work_pwq() is:static struct pool_workqueue *get_work_pwq(struct work_struct *work){ unsigned long data = atomic_long_read(&work->data); if (data & WORK_STRUCT_PWQ) return work_struct_pwq(data); else return NULL;}WORK_STRUCT_PWQ is 0x4:>>> print(repr(prog['WORK_STRUCT_PWQ']))Object(prog, 'enum work_flags', value=4)But work->data is 536870912 which is 0x20000000.So, get_work_pwq() returns NULL and we crash in process_one_work():3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);=============================================
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: add filesystem context source name checkIn certain scenarios, for example, during fuzz testing, the sourcename may be NULL, which could lead to a kernel panic. Therefore, anextra check for the source name should be added.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Prevent the use of too small fidsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]The handle_bytes value passed in by the reproducing program is equal to 12.In handle_to_path(), only 12 bytes of memory are allocated for the structurefile_handle->f_handle member, which causes an out-of-bounds access whenaccessing the member parent_block of the structure isofs_fid in isofs,because accessing parent_block requires at least 16 bytes of f_handle.Here, fh_len is used to indirectly confirm that the value of handle_bytesis greater than 3 before accessing parent_block.[1]BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cros-ec-tunnel: defer probe if parent EC is not presentWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parentdevice will not be found, leading to NULL pointer dereference.That can also be reproduced by unbinding the controller driver and thenloading i2c-cros-ec-tunnel module (or binding the device).[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058[ 271.998215] #PF: supervisor read access in kernel mode[ 272.003351] #PF: error_code(0x0000) - not-present page[ 272.008485] PGD 0 P4D 0[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel][ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0[ 272.129155] Call Trace:[ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110[ 272.137985] platform_probe+0x69/0xa0[ 272.141652] really_probe+0x152/0x310[ 272.145318] __driver_probe_device+0x77/0x110[ 272.149678] driver_probe_device+0x1e/0x190[ 272.153864] __driver_attach+0x10b/0x1e0[ 272.157790] ? driver_attach+0x20/0x20[ 272.161542] bus_for_each_dev+0x107/0x150[ 272.165553] bus_add_driver+0x15d/0x270[ 272.169392] driver_register+0x65/0x110[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698][ 272.182617] do_one_initcall+0x110/0x350[ 272.186543] ? security_kernfs_init_security+0x49/0xd0[ 272.191682] ? __kernfs_new_node+0x1b9/0x240[ 272.195954] ? security_kernfs_init_security+0x49/0xd0[ 272.201093] ? __kernfs_new_node+0x1b9/0x240[ 272.205365] ? kernfs_link_sibling+0x105/0x130[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0[ 272.214773] ? kernfs_activate+0x57/0x70[ 272.218699] ? kernfs_add_one+0x118/0x160[ 272.222710] ? __kernfs_create_file+0x71/0xa0[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110[ 272.232033] ? internal_create_group+0x453/0x4a0[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0[ 272.241355] ? __free_frozen_pages+0x1dc/0x420[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0[ 272.250505] ? load_module+0x1509/0x16f0[ 272.254431] do_init_module+0x60/0x230[ 272.258181] __se_sys_finit_module+0x27a/0x370[ 272.262627] do_syscall_64+0x6a/0xf0[ 272.266206] ? do_syscall_64+0x76/0xf0[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 272.279887] RIP: 0033:0x7b9309168d39[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ti: icss-iep: Fix possible NULL pointer dereference for perout requestThe ICSS IEP driver tracks perout and pps enable state with flags.Currently when disabling pps and perout signals during icss_iep_exit(),results in NULL pointer dereference for perout.To fix the null pointer dereference issue, the icss_iep_perout_enable_hwfunction can be modified to directly clear the IEP CMP registers whendisabling PPS or PEROUT, without referencing the ptp_perout_requeststructure, as its contents are irrelevant in this case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After "complete" becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree'sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user's PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registeredRussell King reports that a system with mv88e6xxx dereferences a NULLpointer when unbinding this driver:https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/The crash seems to be in devlink_region_destroy(), which is not NULLtolerant but is given a NULL devlink global region pointer.At least on some chips, some devlink regions are conditionally registeredsince the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue;These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chipdoes not have an STU or PVT, it should crash like this.To fix the issue, avoid unregistering those regions which are NULL, i.e.were skipped at mv88e6xxx_setup_devlink_regions_global() time.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error pathIn the for loop used to allocate the loc_array and bmap for each port, amemory leak is possible when the allocation for loc_array succeeds,but the allocation for bmap fails. This is because when the control flowgoes to the label free_eth_finfo, only the allocations starting from(i-1)th iteration are freed.Fix that by freeing the loc_array in the bmap allocation error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btrtl: Prevent potential NULL dereferenceThe btrtl_initialize() function checks that rtl_load_file() eitherhad an error or it loaded a zero length file. However, if it loadeda zero length file then the error code is not set correctly. Itresults in an error pointer vs NULL bug, followed by a NULL pointerdereference. This was detected by Smatch:drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,avs_component_probe() does not check for this case, which results in aNULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Purge vif txq in ieee80211_do_stop()After ieee80211_do_stop() SKB from vif's txq could still be processed.Indeed another concurrent vif schedule_and_wake_txq call could causethose packets to be dequeued (see ieee80211_handle_wake_tx_queue())without checking the sdata current state.Because vif.drv_priv is now cleared in this function, this could lead todriver crash.For example in ath12k, ahvif is store in vif.drv_priv. Thus ifath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can beNULL, leading the ath12k_warn(ahvif->ah,...) call in this function totrigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158To avoid that, empty vif's txq at ieee80211_do_stop() so no packet couldbe dequeued after ieee80211_do_stop() (new packets cannot be queuedbecause SDATA_STATE_RUNNING is cleared at this point).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: at76c50x: fix use after free access in at76_disconnectThe memory pointed to by priv is freed at the end of at76_delete_devicefunction (using ieee80211_free_hw). But the code then accesses the udevfield of the freed object to put the USB device. This may also lead to amemory leak of the usb device. Fix this by using udev from interface.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udmabuf: fix a buf size overflow issue during udmabuf creationby casting size_limit_mb to u64 when calculate pglimit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registrationResolve kernel panic while accessing IRQ handler associated with thegenerated IRQ. This is done by acquiring the spinlock and storing thecurrent interrupt state before handling the interrupt request usinggeneric_handle_irq.A previous fix patch was submitted where 'generic_handle_irq' wasreplaced with 'handle_nested_irq'. However, this change also causesthe kernel panic where after determining which GPIO triggered theinterrupt and attempting to call handle_nested_irq with the mappedIRQ number, leads to a failure in locating the registered handler.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mei: vsc: Fix fortify-panic caused by invalid counted_by() usegcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]and the vsc-tp.c code is using this in a wrong way. len does not containthe available size in the buffer, it contains the actual packet length*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc tobuf[] the fortify-panic handler gets triggered:[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0[ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50...[ 80.843175] __fortify_panic+0x9/0xb[ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw][ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110[ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc][ 80.843270] mei_reset+0x11d/0x420 [mei]The easiest fix would be to just drop the counted-by but with the exceptionof the ack buffer in vsc_tp_xfer_helper() which only contains enough roomfor the packet-header, all other uses of vsc_tp_packet always use a bufferof VSC_TP_MAX_XFER_SIZE bytes for the packet.Instead of just dropping the counted-by, split the vsc_tp_packet structdefinition into a header and a full-packet definition and use a fixedsize buf[] in the packet definition, this way fortify-source bufferoverrun checking still works when enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mcb: fix a double free bug in chameleon_parse_gdd()In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'would be released in mcb_device_register() via put_device().Thus, goto 'err' label and free 'mdev' again causes a double free.Just return if mcb_device_register() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()With ACPI in place, gicv2m_get_fwnode() is registered with the pcisubsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtimeduring a PCI host bridge probe. But, the call back is wrongly marked as__init, causing it to be freed, while being registered with the PCIsubsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548This is easily reproducible on a Juno board with ACPI boot.Retain the function for later use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()The function xdp_convert_buff_to_frame() may return NULL if it failsto correctly convert the XDP buffer into an XDP frame due to memoryconstraints, internal errors, or invalid data. Failing to check for NULLmay lead to a NULL pointer dereference if the result is used later inprocessing, potentially causing crashes, data corruption, or undefinedbehavior.On XDP redirect failure, the associated page must be released explicitlyif it was previously retained via get_page(). Failing to do so may resultin a memory leak, as the pages reference count is not decremented.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/eevdf: Fix se->slice being set to U64_MAX and resulting crashThere is a code path in dequeue_entities() that can set the slice of asched_entity to U64_MAX, which sometimes results in a crash.The offending case is when dequeue_entities() is called to dequeue adelayed group entity, and then the entity's parent's dequeue is delayed.In that case:1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.2. The first for_each_sched_entity() loop dequeues the entity.3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent.4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_.5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX.This throws off subsequent calculations with potentially catastrophicresults. A manifestation we saw in production was:6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number.7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number.8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number.9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number.10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow.11. Nothing appears to be eligible, so pick_eevdf() returns NULL.12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes.Dumping the cfs_rq states from the core dumps with drgn showed tell-talehuge vruntime ranges and bogus vlag values, and I also traced se->slicebeing set to U64_MAX on live systems (which was usually "benign" sincethe rest of the runqueue needed to be in a particular state to crash).Fix it in dequeue_entities() by always setting slice from the firstnon-empty cfs_rq.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix NULL pointer dereference in tipc_mon_reinit_self()syzbot reported:tipc: Node number set to 1055423674Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: events tipc_net_finalize_workRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ...RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400There is a racing condition between workqueue created when enablingbearer and another thread created when disabling bearer right afterthat as follow:enabling_bearer | disabling_bearer--------------- | ----------------tipc_disc_timeout() |{ | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | {} | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | }tipc_net_finalize_work() | }{ | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer()Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq().This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fixufshcd_abort_one racing issue").
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: return EIO on RAID1 block group write pointer mismatchThere was a bug report about a NULL pointer dereference in__btrfs_add_free_space_zoned() that ultimately happens because aconversion from the default metadata profile DUP to a RAID1 profile on twodisks.The stack trace has the following signature: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ end trace 0000000000000000 ]---The 1st line is the most interesting here: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profileWhen a RAID1 block-group is created and a write pointer mismatch betweenthe disks in the RAID set is detected, btrfs sets the alloc_offset to thelength of the block group marking it as full. Afterwards the code expectsthat a balance operation will evacuate the data in this block-group andrepair the problems.But before this is possible, the new space of this block-group will beaccounted in the free space cache. But in __btrfs_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()A race can occur between the MCQ completion path and the abort handler:once a request completes, __blk_mq_free_request() sets rq->mq_hctx toNULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call inufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer isdereferenced, the kernel will crash.Add a NULL check for the returned hwq pointer. If hwq is NULL, log anerror and return FAILED, preventing a potential NULL-pointerdereference. As suggested by Bart, the ufshcd_cmd_inflight() check isremoved.This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fixufshcd_abort_one racing issue").This is found by our static analysis tool KNighter.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scpi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scmi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. apple_soc_cpufreq_get_rate() does not checkfor this case, which results in a NULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reference leak in pci_register_host_bridge()If device_register() fails, call put_device() to give up the reference toavoid a memory leak, per the comment at device_register().Found by code review.[bhelgaas: squash Dan Carpenter's double free fix fromhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: fix PM resume warningFixed warning on PM resume as shown below caused due to uninitializedstruct nand_operation that checks chip select field :WARN_ON(op->cs >= nanddev_ntargets(&chip->base)[ 14.588522] ------------[ cut here ]------------[ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8[ 14.588553] Modules linked in: bdc udc_core[ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16[ 14.588590] Tainted: [W]=WARN[ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree)[ 14.588598] Call trace:[ 14.588604] dump_backtrace from show_stack+0x18/0x1c[ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c[ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c[ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c[ 14.588653] r5:c08d40b0 r4:c1003cb0[ 14.588656] dump_stack from __warn+0x84/0xe4[ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194[ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000[ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8[ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048[ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150[ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040[ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54[ 14.588735] r5:00000010 r4:c0840a50[ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c[ 14.588757] dpm_run_callback from device_resume+0xc0/0x324[ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010[ 14.588779] device_resume from dpm_resume+0x130/0x160[ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0[ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20[ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414[ 14.588826] r4:00000010[ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8[ 14.588848] r5:c228a414 r4:00000000[ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc[ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000[ 14.588871] r4:00000003[ 14.588874] pm_suspend from state_store+0x74/0xd0[ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003[ 14.588892] state_store from kobj_attr_store+0x1c/0x28[ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250[ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c[ 14.588936] r5:c3502900 r4:c0d92a48[ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0[ 14.588956] r5:c3502900 r4:c3501f40[ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420[ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00[ 14.588983] r4:c042a88c[ 14.588987] vfs_write from ksys_write+0x74/0xe4[ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00[ 14.589008] r4:c34f7f00[ 14.589011] ksys_write from sys_write+0x10/0x14[ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004[ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c[ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)[ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001[ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78[ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8[ 14.589065] ---[ end trace 0000000000000000 ]---The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, whendoing PM resume operation in compliance with the controller support for singledie nand chip. Switching from nand_reset_op() to nan---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl-qspi: use devm function instead of driver removeDriver use devm APIs to manage clk/irq/resources and register the spicontroller, but the legacy remove function will be called first duringdevice detach and trigger kernel panic. Drop the remove function and usedevm_add_action_or_reset() for driver cleanup to ensure the releasesequence.Trigger kernel panic on i.MX8MQ byecho 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pciehp: Avoid unnecessary device replacement checkHot-removal of nested PCI hotplug ports suffers from a long-standing racecondition which can lead to a deadlock: A parent hotplug port acquirespci_lock_rescan_remove(), then waits for pciehp to unbind from a childhotplug port. Meanwhile that child hotplug port tries to acquirepci_lock_rescan_remove() as well in order to remove its own children.The deadlock only occurs if the parent acquires pci_lock_rescan_remove()first, not if the child happens to acquire it first.Several workarounds to avoid the issue have been proposed and discardedover the years, e.g.:https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/A proper fix is being worked on, but needs more time as it is nontrivialand necessarily intrusive.Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement duringsystem sleep") provokes more frequent occurrence of the deadlock whenremoving more than one Thunderbolt device during system sleep. The commitsought to detect device replacement, but also triggered on device removal.Differentiating reliably between replacement and removal is impossiblebecause pci_get_dsn() returns 0 both if the device was removed, as well asif it was replaced with one lacking a Device Serial Number.Avoid the more frequent occurrence of the deadlock by checking whether thehotplug port itself was hot-removed. If so, there's no sense in checkingwhether its child device was replaced.This works because the ->resume_noirq() callback is invoked in top-downorder for the entire hierarchy: A parent hotplug port detecting devicereplacement (or removal) marks all children as removed usingpci_dev_set_disconnected() and a child hotplug port can then reliablydetect being removed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: avoid NULL pointer dereference in dbg callcifs_server_dbg() implies server to be non-NULL somove call under condition to avoid NULL pointer dereference.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mops: Do not dereference src reg for a set operationThe source register is not used for SET* and reading it can result ina UBSAN out-of-bounds array access error, specifically when the MOPSexception is taken from a SET* sequence with XZR (reg 31) as thesource. Architecturally this is the only case where a src/dst/sizefield in the ESR can be reported as 31.Prior to 2de451a329cf662b the code in do_el0_mops() was benign as theuse of pt_regs_read_reg() prevented the out-of-bounds access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix deadlock in ivpu_ms_cleanup()Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume afterfile_priv->ms_lock is acquired.During a failure in runtime resume, a cold boot is executed, whichcalls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup()that acquires file_priv->ms_lock and causes the deadlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix PM related deadlocks in MS IOCTLsPrevent runtime resume/suspend while MS IOCTLs are in progress.Failed suspend will call ivpu_ms_cleanup() that would try to acquirefile_priv->ms_lock, which is already held by the IOCTLs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has adivide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()returns zero.This is presumably just a theoretical problem: COMPILE_TEST overridesthe dependency on RALINK which would select COMMON_CLK. Regardless it'sa good idea to check for the error explicitly to avoid divide-by-zero.Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()Add error handling to propagate amdgpu_cgs_create_device() failuresto the caller. When amdgpu_cgs_create_device() fails, release hwmgrand return -ENOMEM to prevent null pointer dereference.[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: debugfs hang_hws skip GPU with MESdebugfs hang_hws is used by GPU reset test with HWS, for MES this crashthe kernel with NULL pointer access because dqm->packet_mgr is not setupfor MES path.Skip GPU with MES for now, MES hang_hws debugfs interface will besupported later.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix NULL dereferences in ef100_process_design_param()Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point.Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: pidff: Fix null pointer dereference in pidff_find_fieldsThis function triggered a null pointer dereference if used to search fora report that isn't implemented on the device. This happened both foroptional and required reports alike.The same logic was applied to pidff_find_special_field and althoughpidff_init_fields should return an error earlier if one of the requiredreports is missing, future modifications could change this logic andresurface this possible null pointer dereference again.LKML bug report:https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: don't allow datadir onlyIn theory overlayfs could support upper layer directly referring to a datalayer, but there's no current use case for this.Originally, when data-only layers were introduced, this wasn't allowed,only introduced by the "datadir+" feature, but without actually handlingthis case, resulting in an Oops.Fix by disallowing datadir without lowerdir.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: clean up FDB, MDB, VLAN entries on unbindAs explained in many places such as commit b117e1e8a86d ("net: dsa:delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written giventhe assumption that higher layers have balanced additions/deletions.As such, it only makes sense to be extremely vocal when thoseassumptions are violated and the driver unbinds with entries stillpresent.But Ido Schimmel points out a very simple situation where that is wrong:https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/(also briefly discussed by me in the aforementioned commit).Basically, while the bridge bypass operations are not something that DSAexplicitly documents, and for the majority of DSA drivers this APIsimply causes them to go to promiscuous mode, that isn't the case forall drivers. Some have the necessary requirements for bridge bypassoperations to do something useful - see dsa_switch_supports_uc_filtering().Although in tools/testing/selftests/net/forwarding/local_termination.sh,we made an effort to popularize better mechanisms to manage addressfilters on DSA interfaces from user space - namely macvlan for unicast,and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, thefact is that 'bridge fdb add ... self static local' also exists askernel UAPI, and might be useful to someone, even if only for a quickhack.It seems counter-productive to block that path by implementing shim.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPPin order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() fromrunning, although we could do that.Accepting that cleanup is necessary seems to be the only option.Especially since we appear to be coming back at this from a differentangle as well. Russell King is noticing that the WARN_ON() triggers evenfor VLANs:https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/What happens in the bug report above is that dsa_port_do_vlan_del() fails,then the VLAN entry lingers on, and then we warn on unbind and leak it.This is not a straight revert of the blamed commit, but we now add aninformational print to the kernel log (to still have a way to seethat bugs exist), and some extra comments gathered from past years'experience, to justify the logic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupportedRussell King reports that on the ZII dev rev B, deleting a bridge VLANfrom a user port fails with -ENOENT:https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(),which tries to find an MST entry in &chip->msts associated with the SID,but fails and returns -ENOENT as such.But we know that this chip does not support MST at all, so that is notsurprising. The question is why does the guard in mv88e6xxx_mst_put()not exit early: if (!sid) return 0;And the answer seems to be simple: the sid comes from vlan.sid whichsupposedly was previously populated by mv88e6xxx_vtu_get().But some chip->info->ops->vtu_getnext() implementations do not populatevlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which isjust residual stack memory.Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridgeVLAN mapped to the default MSTI. For some chips, SID 0 is valid andinstalled by mv88e6xxx_stu_setup(). A chip which does not support theSTU would implicitly only support mapping all VLANs to the default MSTI,so although SID 0 is not valid, it would be sufficient, if we were tozero-initialize the vlan structure, to fix the bug, due to thecoincidence that a test for vlan.sid == 0 already exists and leads tothe same (correct) behavior.Another option which would be sufficient would be to add a test formv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the onewhich already exists in mv88e6xxx_mst_get(). But that placement meansthe caller will have to dereference vlan.sid, which means it will accessuninitialized memory, which is not nice even if it ignores it later.So we end up making both modifications, in order to not rely just on thesid == 0 coincidence, but also to avoid having uninitialized structurefields which might get temporarily accessed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Silence oversized kvmalloc() warningsyzkaller triggered an oversized kvmalloc() warning.Silence it by adding __GFP_NOWARN.syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Use local fence in error path of xe_migrate_clearThe intent of the error path in xe_migrate_clear is to wait on locallygenerated fence and then return. The code is waiting on m->fence whichcould be the local fence but this is only stable under the job mutexleading to a possible UAF. Fix code to wait on local fence.(cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: txgbe: fix memory leak in txgbe_probe() error pathWhen txgbe_sw_init() is called, memory is allocated for wx->rss_keyin wx_init_rss_key(). However, in txgbe_probe() function, the subsequenterror paths after txgbe_sw_init() don't free the rss_key. Fix that byfreeing it in error path along with wx->mac_table.Also change the label to which execution jumps when txgbe_sw_init()fails, because otherwise, it could lead to a double free for rss_key,when the mac_table allocation fails in wx_sw_init().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: fix missing ring index trim on error pathCommit under Fixes converted tx_prod to be free running but missedmasking it on the Tx error path. This crashes on error conditions,for example when DMA mapping fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ngbe: fix memory leak in ngbe_probe() error pathWhen ngbe_sw_init() is called, memory is allocated for wx->rss_keyin wx_init_rss_key(). However, in ngbe_probe() function, the subsequenterror paths after ngbe_sw_init() don't free the rss_key. Fix that byfreeing it in error path along with wx->mac_table.Also change the label to which execution jumps when ngbe_sw_init()fails, because otherwise, it could lead to a double free for rss_key,when the mac_table allocation fails in wx_sw_init().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igc: fix PTM cycle trigger logicWriting to clear the PTM status 'valid' bit while the PTM cycle istriggered results in unreliable PTM operation. To fix this, clear thePTM 'trigger' and status after each PTM transaction.The issue can be reproduced with the following:$ sudo phc2sys -R 1000 -O 0 -i tsn0 -mNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way toquickly reproduce the issue.PHC2SYS exits with:"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction failsThis patch also fixes a hang in igc_probe() when loading the igcdriver in the kdump kernel on systems supporting PTM.The igc driver running in the base kernel enables PTM trigger inigc_probe(). Therefore the driver is always in PTM trigger mode,except in brief periods when manually triggering a PTM cycle.When a crash occurs, the NIC is reset while PTM trigger is enabled.Due to a hardware problem, the NIC is subsequently in a bad busmasterstate and doesn't handle register reads/writes. When runningigc_probe() in the kdump kernel, the first register access to a NICregister hangs driver probing and ultimately breaks kdump.With this patch, igc has PTM trigger disabled most of the time,and the trigger is only enabled for very brief (10 - 100 us) periodswhen manually triggering a PTM cycle. Chances that a crash occursduring a PTM trigger are not 0, but extremely reduced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix WARN_ON(!ctx) in __free_event() for partial initMove the get_ctx(child_ctx) call and the child_event->ctx assignment tooccur immediately after the child event is allocated. Ensure thatchild_event->ctx is non-NULL before any subsequent error path withininherit_event calls free_event(), satisfying the assumptions of thecleanup code.Details:There's no clear Fixes tag, because this bug is a side-effect ofmultiple interacting commits over time (up to 15 years old), nota single regression.The code initially incremented refcount then assigned contextimmediately after the child_event was created. Later, an earlyvalidity check for child_event was added before therefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check wasadded, assuming event->ctx is valid if the pmu_ctx is valid.The problem is that the WARN_ON_ONCE() could trigger after the initialcheck passed but before child_event->ctx was assigned, violating itsprecondition. The solution is to assign child_event->ctx right afterits initial validation. This ensures the context exists for anysubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().To resolve it, defer the refcount update and child_event->ctx assignmentdirectly after child_event->pmu_ctx is set but before checking if theparent event is orphaned. The cleanup routine depends onevent->pmu_ctx being non-NULL before it verifies event->ctx isnon-NULL. This also maintains the author's original intent of passingin child_ctx to find_get_pmu_context before its refcount/assignment.[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/net: fix improper handling of bogus negative read/write repliesIn p9_client_write() and p9_client_read_once(), if the serverincorrectly replies with success but a negative write/read count then wewould consider written (negative) <= rsize (positive) because bothvariables were signed.Make variables unsigned to avoid this problem.The reproducer linked below now fails with the following error insteadof a null pointer deref:9pnet: bogus RWRITE count (4294967295 > 3)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()The variable d->name, returned by devm_kasprintf(), could be NULL.A pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: make wait_context part of q_infoMake the wait_context a full part of the q_info struct ratherthan a stack variable that goes away after pdsc_adminq_post()is done so that the context is still available after the waitloop has given up.There was a case where a slow development firmware causedthe adminq request to time out, but then later the FW finallyfinished the request and sent the interrupt. The handler triedto complete_all() the completion context that had been createdon the stack in pdsc_adminq_post() but no longer existed.This caused bad pointer usage, kernel crashes, and much wailingand gnashing of teeth.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL resultIf the FW doesn't support the PDS_CORE_CMD_FW_CONTROL commandthe driver might at the least print garbage and at the worstcrash when the user runs the "devlink dev info" devlink command.This happens because the stack variable fw_list is not 0initialized which results in fw_list.num_fw_slots being agarbage value from the stack. Then the driver tries to accessfw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the endof the array.Fix this by initializing the fw_list and by not failingcompletely if the devcmd fails because other useful informationis printed via devlink dev info even if the devcmd fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table()Add NULL check for mlx5_get_flow_namespace() returns inmlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to preventNULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSIpointer values"), we need to perform a null pointer check on the returnvalue of ice_get_vf_vsi() before using it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: qfq: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of qfq, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.This patch checks whether the class was already added to the agg->activelist (cl_is_active) before doing the addition to cater for the reentrantcase.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of ets, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whetherthe class was already added to the active_list (cl_is_active) beforedoing the addition to cater for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: drr: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of drr, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whether theclass was already added to the active_list (cl_is_active) before addingto the list to cover for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: adjust subpage bit start based on sectorsizeWhen running machines with 64k page size and a 16k nodesize we startedseeing tree log corruption in production. This turned out to be becausewe were not writing out dirty blocks sometimes, so this in fact affectsall metadata writes.When writing out a subpage EB we scan the subpage bitmap for a dirtyrange. If the range isn't dirty we do bit_start++;to move onto the next bit. The problem is the bitmap is based on thenumber of sectors that an EB has. So in this case, we have a 64kpagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4bits for every node. With a 64k page size we end up with 4 nodes perpage.To make this easier this is how everything looks[0 16k 32k 48k ] logical address[0 4 8 12 ] radix tree offset[ 64k page ] folio[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers[ | | | | | | | | | | | | | | | | ] bitmapNow we use all of our addressing based on fs_info->sectorsize_bits, soas you can see the above our 16k eb->start turns into radix entry 4.When we find a dirty range for our eb, we correctly do bit_start +=sectors_per_node, because if we start at bit 0, the next bit for thenext eb is 4, to correspond to eb->start 16k.However if our range is clean, we will do bit_start++, which will nowput us offset from our radix tree entries.In our case, assume that the first time we check the bitmap the block isnot dirty, we increment bit_start so now it == 1, and then we looparound and check again. This time it is dirty, and we go to find thatstart using the following equation start = folio_start + bit_start * fs_info->sectorsize;so in the case above, eb->start 0 is now dirty, and we calculate startas 0 + 1 * fs_info->sectorsize = 4096 4096 >> 12 = 1Now we're looking up the radix tree for 1, and we won't find an eb.What's worse is now we're using bit_start == 1, so we do bit_start +=sectors_per_node, which is now 5. If that eb is dirty we will run intothe same thing, we will look at an offset that is not populated in theradix tree, and now we're skipping the writeout of dirty extent buffers.The best fix for this is to not use sectorsize_bits to address nodes,but that's a larger change. Since this is a fs corruption problem fixit simply by always using sectors_per_node to increment the start bit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_directionActually check if the passed pointers are valid, before writing to them.This also fixes a USBAN warning:UBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25load of value 255 is not a valid value for type '_Bool'This is because playback_only is uninitialized and is not written to, asthe playback-only property is absent.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAMIf the mtk_poll_rx() function detects the MTK_RESETTING flag, it willjump to release_desc and refill the high word of the SDP on the 4GB RFB.Subsequently, mtk_rx_clean will process an incorrect SDP, leading to apanic.Add patch from MediaTek's SDK to resolve this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.When generating the MSR_IA32_PEBS_ENABLE value that will be loaded onVM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLEvalue. Consulting only the host kernel's host vs. guest masks results inrunning the guest with PEBS enabled even when the guest doesn't want to usePEBS. Because KVM uses perf events to proxy the guest virtual PMU, simplylooking at exclude_host can't differentiate between events created by hostuserspace, and events created by KVM on behalf of the guest.Running the guest with PEBS unexpectedly enabled typically manifests ascrashes due to a near-infinite stream of #PFs. E.g. if the guest hasn'twritten MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' whentrying to record PEBS events.The issue is most easily reproduced by running `perf kvm top` from beforecommit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (afterwhich, `perf kvm top` effectively stopped using PEBS). The userspace sideof perf creates a guest-only PEBS event, which intel_guest_get_msrs()misconstrues a guest-*owned* PEBS event.Arguably, this is a userspace bug, as enabling PEBS on guest-only eventssimply cannot work, and userspace can kill VMs in many other ways (thereis no danger to the host). However, even if this is considered to be baduserspace behavior, there's zero downside to perf/KVM restricting PEBS toguest-owned events.Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarilyin two rare situations") fixed the case where host userspace is profilingKVM *and* userspace, but missed the case where userspace is profiling onlyKVM.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()If dib8000_set_dds()'s call to dib8000_read32() returns zero, the resultis a divide-by-zero. Prevent that from happening.Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Verify event formats that have "%*p.."The trace event verifier checks the formats of trace events to make surethat they do not point at memory that is not in the trace event itself orin data that will never be freed. If an event references data that wasallocated when the event triggered and that same data is freed before theevent is read, then the kernel can crash by reading freed memory.The verifier runs at boot up (or module load) and scans the print formatsof the events and checks their arguments to make sure that dereferencedpointers are safe. If the format uses "%*p.." the verifier will ignore it,and that could be dangerous. Cover this case as well.Also add to the sample code a use case of "%*pbl".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Fix accessing BTF.ext core_relo headerUpdate btf_ext_parse_info() to ensure the core_relo header is presentbefore reading its fields. This avoids a potential buffer read overflowreported by the OSS Fuzz project.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Add cond_resched() to ftrace_graph_set_hash()When the kernel contains a large number of functions that can be traced,the loop in ftrace_graph_set_hash() may take a lot of time to execute.This may trigger the softlockup watchdog.Add cond_resched() within the loop to allow the kernel to remainresponsive even when processing a large number of functions.This matches the cond_resched() that is used in other locations of thecode that iterates over all functions that can be traced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe()When snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails,wcd937x_soc_codec_probe() returns without releasing 'wcd937x->clsh_info',which is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free()to prevent potential memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifiIn certain cases, hardware might provide packets with alength greater than the maximum native Wi-Fi header length.This can lead to accessing and modifying fields in the headerwithin the ath12k_dp_rx_h_undecap_nwifi function forDP_RX_DECAP_TYPE_NATIVE_WIFI decap type andpotentially resulting in invalid data access and memory corruption.Add a sanity check before processing the SKB to prevent invaliddata access in the undecap native Wi-Fi function for theDP_RX_DECAP_TYPE_NATIVE_WIFI decap type.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_processCurrently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entryto fetch the next entry from the destination ring. This is incorrect becauseath12k_hal_srng_src_get_next_entry is intended for source rings, not destinationrings. This leads to invalid entry fetches, causing potential data corruption orcrashes due to accessing incorrect memory locations. This happens because thesource ring and destination ring have different handling mechanisms and usingthe wrong function results in incorrect pointer arithmetic and ring management.To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry withath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensuresthat the correct function is used for fetching entries from the destinationring, preventing invalid memory accesses.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHYDSA has 2 kinds of drivers:1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz2. Those who don't: all others. The above methods should be optional.For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),and dsa_switch_resume() calls dsa_user_resume() -> phylink_start().These seem good candidates for setting mac_managed_pm = true becausethat is essentially its definition [1], but that does not seem to be thebiggest problem for now, and is not what this change focuses on.Talking strictly about the 2nd category of DSA drivers here (whichdo not have MAC managed PM, meaning that for their attached PHYs,mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),I have noticed that the following warning from mdio_bus_phy_resume() istriggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP);because the PHY state machine is running.It's running as a result of a previous dsa_user_open() -> ... ->phylink_start() -> phy_start() having been initiated by the user.The previous mdio_bus_phy_suspend() was supposed to have calledphy_stop_machine(), but it didn't. So this is why the PHY is in statePHY_NOLINK by the time mdio_bus_phy_resume() runs.mdio_bus_phy_suspend() did not call phy_stop_machine() because forphylink, the phydev->adjust_link function pointer is NULL. This seems atechnicality introduced by commit fddd91016d16 ("phylib: fix PAL statemachine restart on resume"). That commit was written before phylinkexisted, and was intended to avoid crashing with consumer drivers whichdon't use the PHY state machine - phylink always does, when using a PHY.But phylink itself has historically not been developed withsuspend/resume in mind, and apparently not tested too much in thatscenario, allowing this bug to exist unnoticed for so long. Plus, priorto the WARN_ON(), it would have likely been invisible.This issue is not in fact restricted to type 2 DSA drivers (according tothe above ad-hoc classification), but can be extrapolated to any MACdriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just wherethe issue was reported. Assuming mac_managed_pm is set correctly, aquick search indicates the following other drivers might be affected:$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pmdrivers/net/ethernet/atheros/ag71xx.cdrivers/net/ethernet/microchip/sparx5/sparx5_main.cdrivers/net/ethernet/microchip/lan966x/lan966x_main.cdrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.cdrivers/net/ethernet/freescale/fs_enet/fs_enet-main.cdrivers/net/ethernet/freescale/dpaa/dpaa_eth.cdrivers/net/ethernet/freescale/ucc_geth.cdrivers/net/ethernet/freescale/enetc/enetc_pf_common.cdrivers/net/ethernet/marvell/mvpp2/mvpp2_main.cdrivers/net/ethernet/marvell/mvneta.cdrivers/net/ethernet/marvell/prestera/prestera_main.cdrivers/net/ethernet/mediatek/mtk_eth_soc.cdrivers/net/ethernet/altera/altera_tse_main.cdrivers/net/ethernet/wangxun/txgbe/txgbe_phy.cdrivers/net/ethernet/meta/fbnic/fbnic_phylink.cdrivers/net/ethernet/tehuti/tn40_phy.cdrivers/net/ethernet/mscc/ocelot_net.cMake the existing conditions dependent on the PHY device having aphydev->phy_link_change() implementation equal to the defaultphy_link_change() provided by phylib. Otherwise, we implicitly know thatthe phydev has the phylink-provided phylink_phy_change() callback, andwhen phylink is used, the PHY state machine always needs to be stopped/started on the suspend/resume path. The code is structured as such thatif phydev->phy_link_change() is absent, it is a matter of time until thekernel will crash - no need to further complicate the test.Thus, for the situation where the PM is not managed b---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFsWith commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize stateof zpci_dev's") the code to ignore power off of a PF that has child VFswas changed from a direct return to a goto to the unlock andpci_dev_put() section. The change however left the existing pci_dev_put()untouched resulting in a doubple put. This can subsequently cause a useafter free if the struct pci_dev is released in an unexpected state.Fix this by removing the extra pci_dev_put().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()The selftests added to our CI by Bui Quang Minh recently revealsthat there is a mem leak on the error path of virtnet_xsk_pool_enable():unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interceptionPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested modeon vCPU reset") addressed an issue where a triple fault occurring innested mode could lead to use-after-free scenarios. However, the commitdid not handle the analogous situation for System Management Mode (SMM).This omission results in triggering a WARN when KVM forces a vCPU INITafter SHUTDOWN interception while the vCPU is in SMM. This situation wasreprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple faultThe issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improperemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs todo _something_ sane with the VMCB, since it's technically undefined, andINIT is the least awful choice given KVM's ABI.So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out ofSMM to avoid any weirdness (and the WARN).Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[sean: massage changelog, make it clear this isn't architectural behavior]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Scrub packet on bpf_redirect_peerWhen bpf_redirect_peer is used to redirect packets to a device inanother network namespace, the skb isn't scrubbed. That can lead skbinformation from one namespace to be "misused" in another namespace.As one example, this is causing Cilium to drop traffic when usingbpf_redirect_peer to redirect packets that just went through IPsecdecryption to a container namespace. The following pwru trace shows (1)the packet path from the host's XFRM layer to the container's XFRMlayer where it's dropped and (2) the number of active skb extensions ateach function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2,In this case, there are no XFRM policies in the container's networknamespace so the drop is unexpected. When we decrypt the IPsec packet,the XFRM state used for decryption is set in the skb extensions. Thisinformation is preserved across the netns switch. When we reach theXFRM policy check in the container's netns, __xfrm_policy_check dropsthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRMpolicy can't be found that matches the (host-side) XFRM state used fordecryption.This patch fixes this by scrubbing the packet when usingbpf_redirect_peer, as is done on typical netns switches via vethdevices except skb->mark and skb->tstamp are not zeroed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memblock: Accept allocated memory before use in memblock_double_array()When increasing the array size in memblock_double_array() and the slabis not yet available, a call to memblock_find_in_range() is used toreserve/allocate memory. However, the range returned may not have beenaccepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19bMitigate this by calling accept_memory() on the memory range returnedbefore the slab is available.Prior to v6.12, the accept_memory() interface used a 'start' and 'end'parameter instead of 'start' and 'size', therefore the accept_memory()call must be adjusted to specify 'start + size' for 'end' when applyingto kernels prior to v6.12.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix uninit-value for saddr in do_output_route4syzbot reports for uninit-value for the saddr argument [1].commit 4754957f04f5 ("ipvs: do not use random local source address fortunnels") already implies that the input value of saddrshould be ignored but the code is still reading it which can preventto connect the route. Fix it by changing the argument to ret_saddr.[1]BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)Hardware name: Google Google Compute Engi---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRLWhen userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is notavailable, the kernel crashes:Oops - illegal instruction [#1] [snip]epc : set_tagged_addr_ctrl+0x112/0x15a ra : set_tagged_addr_ctrl+0x74/0x15aepc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10 [snip]status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002 set_tagged_addr_ctrl+0x112/0x15a __riscv_sys_prctl+0x352/0x73c do_trap_ecall_u+0x17c/0x20c andle_exception+0x150/0x15cFix it by checking if Supm is available.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix deadlockThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlockfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connectormutex is only locked if a connection is established and the partner pointeris valid. This resolves a deadlock scenario whereucsi_displayport_remove_partner holds con->mutex waiting fordp_altmode_work to complete while dp_altmode_work attempts to acquire it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: opt3001: fix deadlock due to concurrent flag accessThe threaded IRQ function in this driver is reading the flag twice: once tolock a mutex and once to unlock it. Even though the code setting the flagis designed to prevent it, there are subtle cases where the flag could betrue at the mutex_lock stage and false at the mutex_unlock stage. Thisresults in the mutex not being unlocked, resulting in a deadlock.Fix it by making the opt3001_irq() code generally more robust, reading theflag into a variable and using the variable value at both stages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifoPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop incase pattern_len is equal to zero and the device FIFO is not empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifoPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in casepattern_len is equal to zero and the device FIFO is not empty.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: bcm2835-camera: Initialise dev in v4l2_devCommit 42a2f6664e18 ("staging: vc04_services: Move global g_state tovchiq_state") changed mmal_init to pass dev->v4l2_dev.dev tovchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we gota NULL pointer dereference.Set dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointercould be passed into v4l2_device_register to set it, however that alsohas other effects that would need additional changes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: mtk-pmic-keys - fix possible null pointer dereferenceIn mtk_pmic_keys_probe, the regs parameter is only set if the button isparsed in the device tree. However, on hardware where the button is leftfloating, that node will most likely be removed not to enable thatinput. In that case the code will try to dereference a null pointer.Let's use the regs struct instead as it is defined for all supportedplatforms. Note that it is ok setting the key reg even if that latter isdisabled as the interrupt won't be enabled anyway.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentationCurrently during the multi-link element defragmentation process, themulti-link element length added to the total IEs length when calculatingthe length of remaining IEs after the multi-link element incfg80211_defrag_mle(). This could lead to out-of-bounds access if themulti-link element or its corresponding fragment elements are the lastelements in the IEs buffer.To address this issue, correctly calculate the remaining IEs length bydeducting the multi-link element end offset from total IEs end offset.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Fix missing check for zpci_create_device() error returnThe zpci_create_device() function returns an error pointer that needs tobe checked before dereferencing it as a struct zpci_dev pointer. Add themissing check in __clp_add() where it was missed when adding thescan_list in the fixed commit. Simply not adding the device to the scanlist results in the previous behavior.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: module: Fix out-of-bounds relocation accessThe current code allows rel[j] to access one element past the end of therelocation section. Simplify to num_relocations which is equivalent tothe existing size expression.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Disable iocc if dma-coherent property isn't setIf dma-coherent property isn't set then descriptors are non-cacheableand the iocc shareability bits should be disabled. Without this UFS canend up in an incompatible configuration and suffer from random cacherelated stability issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: integrity: Do not call set_page_dirty_lock()Placing multiple protection information buffers inside the same pagecan lead to oopses because set_page_dirty_lock() can't be called frominterrupt context.Since a protection information buffer is not backed by a file there isno point in setting its page dirty, there is nothing to synchronize.Drop the call to set_page_dirty_lock() and remove the last argument tobio_integrity_unpin_bvec().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: Fix sc7280 lpass potential buffer overflowCase values introduced in commit5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution")cause out of bounds access in arrays of sc7280 driver data (e.g. in caseof RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).Redefine LPASS_MAX_PORTS to consider the maximum possible port id forq6dsp as sc7280 driver utilizes some of those values.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Use is_kdump_kernel() to check for kdumpThe smartpqi driver checks the reset_devices variable to determinewhether special adjustments need to be made for kdump. This has theeffect that after a regular kexec reboot, some driver parameters such asmax_transfer_size are much lower than usual. More importantly, kexecreboot tests have revealed memory corruption caused by the driver logbeing written to system memory after a kexec.Fix this by testing is_kdump_kernel() rather than reset_devices whereappropriate.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: fix memory leak in wl1251_tx_workThe skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup failswith a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: wdm: close race between wdm_open and wdm_wwan_port_stopClearing WDM_WWAN_IN_USE must be the last action orwe can open a chardev whose URBs are still poisoned
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: class: Invalidate USB device pointers on partner unregistrationTo avoid using invalid USB device pointers after a Type-C partnerdisconnects, this patch clears the pointers upon partner unregistration.This ensures a clean state for future connections.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: Prevent possible adminq overflow/stuck conditionThe pds_core's adminq is protected by the adminq_lock, which preventsmore than 1 command to be posted onto it at any one time. This makes itso the client drivers cannot simultaneously post adminq commands.However, the completions happen in a different context, which meansmultiple adminq commands can be posted sequentially and all waitingon completion.On the FW side, the backing adminq request queue is only 16 entrieslong and the retry mechanism and/or overflow/stuck prevention islacking. This can cause the adminq to get stuck, so commands are nolonger processed and completions are no longer sent by the FW.As an initial fix, prevent more than 16 outstanding adminq commands sothere's no way to cause the adminq from getting stuck. This worksbecause the backing adminq request queue will never have more than 16pending adminq commands, so it will never overflow. This is done byreducing the adminq depth to 16.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()Normally do_lock_mount(path, _) is locking a mountpoint pinned by*path and at the time when matching unlock_mount() unlocks thatlocation it is still pinned by the same thing.Unfortunately, for 'beneath' case it's no longer that simple -the object being locked is not the one *path points to. It's themountpoint of path->mnt. The thing is, without sufficient locking->mnt_parent may change under us and none of the locks are heldat that point. The rules are * mount_lock stabilizes m->mnt_parent for any mount m. * namespace_sem stabilizes m->mnt_parent, provided thatm is mounted. * if either of the above holds and refcount of m is positive,we are guaranteed the same for refcount of m->mnt_parent.namespace_sem nests inside inode_lock(), so do_lock_mount() hasto take inode_lock() before grabbing namespace_sem. It doesrecheck that path->mnt is still mounted in the same place aftergetting namespace_sem, and it does take care to pin the dentry.It is needed, since otherwise we might end up with racing mount --move(or umount) happening while we were getting locks; in that casedentry would no longer be a mountpoint and could've been evictedon memory pressure along with its inode - not something you wantwhen grabbing lock on that inode.However, pinning a dentry is not enough - the matching mount isalso pinned only by the fact that path->mnt is mounted on top itand at that point we are not holding any locks whatsoever, sothe same kind of races could end up with all references tothat mount gone just as we are about to enter inode_lock().If that happens, we are left with filesystem being shut down whilewe are holding a dentry reference on it; results are not pretty.What we need to do is grab both dentry and mount at the same time;that makes inode_lock() safe *and* avoids the problem with fs gettingshut down under us. After taking namespace_sem we verify thatpath->mnt is still mounted (which stabilizes its ->mnt_parent) andcheck that it's still mounted at the same place. From that pointon to the matching namespace_unlock() we are guaranteed thatmount/dentry pair we'd grabbed are also pinned by being the mountpointof path->mnt, so we can quietly drop both the dentry reference (asthe current code does) and mnt one - it's OK to do under namespace_sem,since we are not dropping the final refs.That solves the problem on do_lock_mount() side; unlock_mount()also has one, since dentry is guaranteed to stay pinned only untilthe namespace_unlock(). That's easy to fix - just have inode_unlock()done earlier, while it's still pinned by mp->m_dentry.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: leds: fix memory leakA network restart test on a router led to an out-of-memory condition,which was traced to a memory leak in the PHY LED trigger code.The root cause is misuse of the devm API. The registration function(phy_led_triggers_register) is called from phy_attach_direct, notphy_probe, and the unregister function (phy_led_triggers_unregister)is called from phy_detach, not phy_remove. This means the register andunregister functions can be called multiple times for the same PHYdevice, but devm-allocated memory is not freed until the driver isunbound.This also prevents kmemleak from detecting the leak, as the devm APIinternally stores the allocated pointer.Fix this by replacing devm_kzalloc/devm_kcalloc with standardkzalloc/kcalloc, and add the corresponding kfree calls in the unregisterpath.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()The function brcmf_usb_dl_writeimage() calls the functionbrcmf_usb_dl_cmd() but dose not check its return value. The'state.state' and the 'state.bytes' are uninitialized if thefunction brcmf_usb_dl_cmd() fails. It is dangerous to useuninitialized variables in the conditions.Add error handling for brcmf_usb_dl_cmd() to jump to errorhandling path if the brcmf_usb_dl_cmd() fails and the'state.state' and the 'state.bytes' are uninitialized.Improve the error message to report more detailed errorinformation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Flush gso_skb list too during ->change()Previously, when reducing a qdisc's limit via the ->change() operation, onlythe main skb queue was trimmed, potentially leaving packets in the gso_skblist. This could result in NULL pointer dereference when we only checksch->limit against sch->q.qlen.This patch introduces a new helper, qdisc_dequeue_internal(), which ensuresboth the gso_skb list and the main queue are properly flushed when trimmingexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)are updated to use this helper in their ->change() routines.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Disable MACsec offload for uplink representor profileMACsec offload is not supported in switchdev mode for uplinkrepresentors. When switching to the uplink representor profile, theMACsec offload feature must be cleared from the netdevice's features.If left enabled, attempts to add offloads result in a null pointerdereference, as the uplink representor does not support MACsec offloadeven though the feature bit remains set.Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().Kernel log:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASANKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__mutex_lock+0x128/0x1dd0Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ffRSP: 0018:ffff888147a4f160 EFLAGS: 00010206RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400Call Trace: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: handle failure of nfs_get_lock_context in unlock pathWhen memory is insufficient, the allocation of nfs_lock_context innfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treatan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)as valid and proceed to execute rpc_run_task(), this will trigger a NULLpointer dereference in nfs4_locku_prepare. For example:BUG: kernel NULL pointer dereference, address: 000000000000000cPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40Workqueue: rpciod rpc_async_scheduleRIP: 0010:nfs4_locku_prepare+0x35/0xc2Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in:CR2: 000000000000000c---[ end trace 0000000000000000 ]---Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails andreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointerdereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bugCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fIn the function rxe_create_cq, when rxe_cq_from_init fails, the functionrxe_cleanup will be called to handle the allocated resources. In fact,some memory resources have already been freed in the functionrxe_cq_from_init. Thus, this problem will occur.The solution is to let rxe_cleanup do all the work.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free in cifs_fill_direntThere is a race condition in the readdir concurrency process, which mayaccess the rsp buffer after it has been released, triggering thefollowing KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================POC is available in the link [1].The problem triggering process is as follows:Process 1 Process 2--------------------------------------truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_doneSyzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_donemay still visit it in cryptd_queue_worker workqueue.I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1The key of reproduction is that, simd_aead_encrypt is interrupted, leadingto crypto_simd_usable() return false. Thus, the cryptd_queue_worker istriggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)Fix this by holding net reference count before encrypt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix null-ptr-deref in idpf_features_checkidpf_features_check is used to validate the TX packet. skb headerlength is compared with the hardware supported value received fromthe device control plane. The value is stored in the adapter structureand to access it, vport pointer is used. During reset all the vportsare released and the vport pointer that the netdev private structurepoints to is NULL.To avoid null-ptr-deref, store the max header length value in netdevprivate structure. This also helps to cache the value and avoidaccessing adapter pointer in hot path.BUG: kernel NULL pointer dereference, address: 0000000000000068...RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: Limit signal/freq counts in summary output functionsThe debugfs summary output could access uninitialized elements inthe freq_in[] and signal_out[] arrays, causing NULL pointerdereferences and triggering a kernel Oops (page_fault_oops).This patch adds u8 fields (nr_freq_in, nr_signal_out) to track thenumber of initialized elements, with a maximum of 4 per array.The summary output functions are updated to respect these limits,preventing out-of-bounds access and ensuring safe array handling.Widen the label variables because the change confuses GCC aboutmax length of the strings.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freqCurrently, using PEBS-via-PT with a sample frequency instead of a sampleperiod, causes a segfault. For example: BUG: kernel NULL pointer dereference, address: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50That happens because intel_pmu_pebs_event_update_no_drain() assumes all thepebs_enabled bits represent counter indexes, which is not always the case.In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes.The behaviour of PEBS-via-PT with sample frequency is questionable becausealthough a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is notadjusted anyway.Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passingthe mask of counter bits instead of 'size'. Note, prior to the Fixescommit, 'size' would be limited to the maximum counter index, so the issuewas not hit.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix UAF when reloading modulehda_generic_machine_select() appends -idisp to the tplg filename byallocating a new string with devm_kasprintf(), then stores the stringright back into the global variable snd_soc_acpi_intel_hda_machines.When the module is unloaded, this memory is freed, resulting in a globalvariable pointing to freed memory. Reloading the module then triggersa use-after-free:BUG: KFENCE: use-after-free read in string+0x48/0xe0Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix it by copying the match array with devm_kmemdup_array() before wemodify it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: fix skb leaksA few error paths are missing a kfree_skb.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libnvdimm/labels: Fix divide error in nd_label_data_init()If a faulty CXL memory device returns a broken zero LSA size in itsmemory device information (Identify Memory Device (Opcode 4000h), CXLspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimmdriver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]Code and flow:1) CXL Command 4000h returns LSA size = 02) config_size is assigned to zero LSA size (CXL pmem driver):drivers/cxl/pmem.c: .config_size = mds->lsa_size,3) max_xfer is set to zero (nvdimm driver):drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);4) A subsequent DIV_ROUND_UP() causes a division by zero:drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,drivers/nvdimm/label.c- config_size);Fix this by checking the config size parameter by extending anexisting check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()If the 'buf' array received from the user contains an empty string, the'length' variable will be zero. Accessing the 'buf' array element withindex 'length - 1' will result in a buffer overflow.Add a check for an empty string.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix race of buffer access at PCM OSS layerThe PCM OSS layer tries to clear the buffer with the silence data atinitialization (or reconfiguration) of a stream with the explicit callof snd_pcm_format_set_silence() with runtime->dma_area. But this maylead to a UAF because the accessed runtime->dma_area might be freedconcurrently, as it's performed outside the PCM ops.For avoiding it, move the code into the PCM core and perform it insidethe buffer access lock, so that it won't be changed during theoperation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cadence: macb: Fix a possible deadlock in macb_halt_tx.There is a situation where after THALT is set high, TGO stays high aswell. Because jiffies are never updated, as we are in a context withinterrupts disabled, we never exit that loop and have a deadlock.That deadlock was noticed on a sama5d4 device that stayed locked for days.Use retries instead of jiffies so that the timeout really works and we donot have a deadlock anymore.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: insert memory barrier before updating num_fencessmp_store_mb() inserts memory barrier after storing operation.It is different with what the comment is originally aiming so Nullpointer dereference can be happened if memory update is reordered.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: don't warn when if there is a FW erroriwl_trans_reclaim is warning if it is called when the FW is not alive.But if it is called when there is a pending restart, i.e. after a FWerror, there is no need to warn, instead - return silently.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOVRLCG Register Access is a way for virtual functions to safely access GPUregisters in a virtualized environment., including TLB flushes andregister reads. When multiple threads or VFs try to access the sameregisters simultaneously, it can lead to race conditions. By using theRLCG interface, the driver can serialize access to the registers. Thismeans that only one thread can access the registers at a time,preventing conflicts and ensuring that operations are performedcorrectly. Additionally, when a low-priority task holds a mutex that ahigh-priority task needs, ie., If a thread holding a spinlock tries toacquire a mutex, it can lead to priority inversion. register access inamdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.The call stack shows that the function amdgpu_virt_rlcg_reg_rw is beingcalled, which attempts to acquire the mutex. This function is invokedfrom amdgpu_sriov_wreg, which in turn is called fromgmc_v11_0_flush_gpu_tlb.The [ BUG: Invalid wait context ] indicates that a thread is trying toacquire a mutex while it is in a context that does not allow it to sleep(like holding a spinlock).Fixes the below:[ 253.013423] =============================[ 253.013434] [ BUG: Invalid wait context ][ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE[ 253.013464] -----------------------------[ 253.013475] kworker/0:1/10 is trying to lock:[ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.013815] other info that might help us debug this:[ 253.013827] context-{4:4}[ 253.013835] 3 locks held by kworker/0:1/10:[ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680[ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680[ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu][ 253.014154] stack backtrace:[ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14[ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024[ 253.014224] Workqueue: events work_for_cpu_fn[ 253.014241] Call Trace:[ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0[ 253.014275] dump_stack+0x10/0x20[ 253.014287] __lock_acquire+0xa47/0x2810[ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.014321] lock_acquire+0xd1/0x300[ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.014562] ? __lock_acquire+0xa6b/0x2810[ 253.014578] __mutex_lock+0x85/0xe20[ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.014782] ? sched_clock_noinstr+0x9/0x10[ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.014808] ? local_clock_noinstr+0xe/0xc0[ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.015029] mutex_lock_nested+0x1b/0x30[ 253.015044] ? mutex_lock_nested+0x1b/0x30[ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu][ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu][ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu][ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu][ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu][ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5[ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu][ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu][ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu][ 253.0170---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Fix NULL pointer dereference when nosmp is usedWith nosmp in cmdline, other CPUs are not brought up, leavingtheir cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()dereferences these NULL pointers, causing panic.Panic backtrace:[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8...[ 0.403255] [] cppc_allow_fast_switch+0x6a/0xd4...Kernel panic - not syncing: Attempted to kill init![ rjw: New subject ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: fix a potential crash on gso_skb handlingSFQ has an assumption of always being able to queue at least one packet.However, after the blamed commit, sch->q.len can be inflated by packetsin sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followedby an immediate drop.Fix sfq_drop() to properly clear q->tail in this situation.ip netns add lbip link add dev to-lb type veth peer name in-lb netns lbethtool -K to-lb tso off # force qdisc to requeue gso_skbip netns exec lb ethtool -K in-lb gro on # enable NAPIip link set dev to-lb upip -netns lb link set dev in-lb upip addr add dev to-lb 192.168.20.1/24ip -netns lb addr add dev in-lb 192.168.20.2/24tc qdisc replace dev to-lb root sfq limit 100ip netns exec lb netservernetperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: add missing NULL check for gve_alloc_pending_packet() in TX DQOgve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()did not check for this case before dereferencing the returned pointer.Add a missing NULL check to prevent a potential NULL pointerdereference when allocation fails.This improves robustness in low-memory scenarios.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Tx scheduler error handling in XDP callbackWhen the XDP program is loaded, the XDP callback adds new Tx queues.This means that the callback must update the Tx scheduler with the newqueue number. In the event of a Tx scheduler failure, the XDP callbackshould also fail and roll back any changes previously made for XDPpreparation.The previous implementation had a bug that not all changes made by theXDP callback were rolled back. This caused the crash with the followingcall trace:[ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5[ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI[ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)[ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022[ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice][...][ +0.002715] Call Trace:[ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29[ +0.003922] ? die_addr+0x3c/0x60[ +0.003319] ? exc_general_protection+0x17c/0x400[ +0.004707] ? asm_exc_general_protection+0x26/0x30[ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice][ +0.004835] ice_napi_poll+0x665/0x680 [ice][ +0.004320] __napi_poll+0x28/0x190[ +0.003500] net_rx_action+0x198/0x360[ +0.003752] ? update_rq_clock+0x39/0x220[ +0.004013] handle_softirqs+0xf1/0x340[ +0.003840] ? sched_clock_cpu+0xf/0x1f0[ +0.003925] __irq_exit_rcu+0xc2/0xe0[ +0.003665] common_interrupt+0x85/0xa0[ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40[ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690Fix this by performing the missing unmapping of XDP queues fromq_vectors and setting the XDP rings pointer back to NULL after all thosequeues are released.Also, add an immediate exit from the XDP callback in case of ringpreparation failure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: Add NULL check in udma_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,udma_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: pm8941: Add NULL check in wled_configure()devm_kasprintf() returns NULL when memory allocation fails. Currently,wled_configure() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()devm_kasprintf() returns NULL when memory allocation fails. Currently,aspeed_lpc_enable_snoop() does not check for this case, which results in aNULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.[arj: Fix Fixes: tag to use subject from 3772e5da4454]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Don't call calipso functions for AF_INET sk.syzkaller reported a null-ptr-deref in txopt_get(). [0]The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,so struct ipv6_pinfo was NULL there.However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6is always set in inet6_create(), meaning the socket was not IPv6 one.The root cause is missing validation in netlbl_conn_setattr().netlbl_conn_setattr() switches branches based on structsockaddr.sa_family, which is passed from userspace. However,netlbl_conn_setattr() does not check if the address family matchesthe socket.The syzkaller must have called connect() for an IPv6 address onan IPv4 socket.We have a proper validation in tcp_v[46]_connect(), butsecurity_socket_connect() is called in the earlier stage.Let's copy the validation to netlbl_conn_setattr().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]RIP: 0010:Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00cRDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9eR10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0PKRU: 80000000Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f901b61a12dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12dRDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Make sure modelist not set on unregistered consoleIt looks like attempting to write to the "store_modes" sysfs node willrun afoul of unregistered consoles:UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28index -1 is out of range for type 'fb_info *[32]'... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439static struct fb_info *fbcon_registered_fb[FB_MAX];...static signed char con2fb_map[MAX_NR_CONSOLES];...static struct fb_info *fbcon_info_from_console(int console)... return fbcon_registered_fb[con2fb_map[console]];If con2fb_map contains a -1 things go wrong here. Instead, return NULL,as callers of fbcon_info_from_console() are trying to compare againstexisting "info" pointers, so error handling should kick in correctly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()bpf_map_lookup_percpu_elem() helper is also available for sleepable bpfprogram. When BPF JIT is disabled or under 32-bit host,bpf_map_lookup_percpu_elem() will not be inlined. Using it in asleepable bpf program will trigger the warning inbpf_map_lookup_percpu_elem(), because the bpf program only holdsrcu_read_lock_trace lock. Therefore, add the missed check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:configfs-tsm-report: Fix NULL dereference of tsm_opsUnlike sysfs, the lifetime of configfs objects is controlled byuserspace. There is no mechanism for the kernel to find and delete allcreated config-items. Instead, the configfs-tsm-report mechanism has anexpectation that tsm_unregister() can happen at any time and causeestablished config-item access to start failing.That expectation is not fully satisfied. While tsm_report_read(),tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely failif tsm_ops have been unregistered, tsm_report_privlevel_store()tsm_report_provider_show() fail to check for ops registration. Add themissing checks for tsm_ops having been removed.Now, in supporting the ability for tsm_unregister() to always succeed,it leaves the problem of what to do with lingering config-items. Theexpectation is that the admin that arranges for the ->remove() (unbind)of the ${tsm_arch}-guest driver is also responsible for deletion of allopen config-items. Until that deletion happens, ->probe() (reload /bind) of the ${tsm_arch}-guest driver fails.This allows for emergency shutdown / revocation of attestationinterfaces, and requires coordinated restart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in fb_set_var() fails to allocate memory forfb_videomode, later it may lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================The reason is that fb_info->var is being modified in fb_set_var(), andthen fb_videomode_to_var() is called. If it fails to add the mode tofb_info->modelist, fb_set_var() returns error, but does not restore theold value of fb_info->var. Restore fb_info->var on failure the same wayit is done earlier in the function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Cleanup after an allocation errorWhen allocation failures are not cleaned up by the driver, furtherallocation errors will be false-positives, which will cause buffers toremain uninitialized and cause NULL pointer dereferences.Ensure proper cleanup of failed allocations to prevent these issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt: properly flush XDP redirect listsWe encountered following crash when testing a XDP_REDIRECT featurein production:[56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd40f30).[56251.601413] ------------[ cut here ]------------[56251.611357] kernel BUG at lib/list_debug.c:29![56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6.3 #1[56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE[56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025[56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0[56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89[56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246[56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000[56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80[56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18[56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000[56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40[56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000[56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0[56251.831365] PKRU: 55555554[56251.838653] Call Trace:[56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa[56251.860243] xdp_do_redirect+0x2d9/0x480[56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en][56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en][56251.885665] ? cpu_max_write+0x1e/0x100[56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5[56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en][56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en][56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5[56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5[56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5[56251.944250] __napi_poll+0x2b/0x160[56251.951155] bpf_trampoline_6442548651+0x79/0x123[56251.959262] __napi_poll+0x5/0x160[56251.966037] net_rx_action+0x3d2/0x880[56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5[56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5[56251.989262] ? __hrtimer_run_queues+0x162/0x2a0[56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5[56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5[56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en][56252.019903] handle_softirqs+0xcf/0x270[56252.026650] irq_exit_rcu+0x67/0x90[56252.032933] common_interrupt+0x85/0xa0[56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40[56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420[56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29[56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202[56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000[56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000[56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e[56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860[56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000[56252.146667] ? cpuidle_enter_state+0xab/0x420[56252.153909] cpuidle_enter+0x2d/0x40[56252.160360] do_idle+0x176/0x1c0[56252.166456---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd9335: Fix missing free of regulator suppliesDriver gets and enables all regulator supplies in probe path(wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanupin final error paths and in unbind (missing remove() callback). Thisleads to leaked memory and unbalanced regulator enable count duringprobe errors or unbind.Fix this by converting entire code into devm_regulator_bulk_get_enable()which also greatly simplifies the code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: b53: do not enable EEE on bcm63xxBCM63xx internal switches do not support EEE, but provide multiple RGMIIports where external PHYs may be connected. If one of these PHYs are EEEcapable, we may try to enable EEE for the MACs, which then hangs thesystem on access of the (non-existent) EEE registers.Fix this by checking if the switch actually supports EEE beforeattempting to configure it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not include stack ptr register in precision backtracking bookkeepingYi Lai reported an issue ([1]) where the following warning appearsin kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ...Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); 4302 WARN_ONCE(1, "verifier backtracking bug"); 4303 return -EFAULT; 4304 }With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { asm volatile ( "r2 = 2314885393468386424 ll;" "goto +0;" "if r2 <= r10 goto +3;" "if r1 >= -1835016 goto +0;" "if r2 <= 8 goto +0;" "if r3 <= 0 goto +0;" "exit;" ::: __clobber_all); } SEC("?raw_tp") __naked void bpf_jmp_r10(void) { asm volatile ( "r3 = 0 ll;" "call __bpf_jmp_r10;" "r0 = 0;" "exit;" ::: __clobber_all); }The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (" \ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid __bpf_prog_ret0_warn when jit failssyzkaller reported an issue:WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Modules linked in:CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ...When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not setand bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,but jit failed due to FAULT_INJECTION. As a result, incorrectlytreats the program as valid, when the program runs it calls`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hisi_acc_vfio_pci: bugfix live migration function without VF device driverIf the VF device driver is not loaded in the Guest OS and we attempt toperform device data migration, the address of the migrated data willbe NULL.The live migration recovery operation on the destination side willaccess a null address value, which will cause access errors.Therefore, live migration of VMs without added VF device driversdoes not require device data migration.In addition, when the queue address data obtained by the destinationis empty, device queue recovery processing will not be performed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix WARN() in get_bpf_raw_tp_regssyzkaller reported an issue:WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861Modules linked in:CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4cRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47Tracepoint like trace_mmap_lock_acquire_returned may cause nested callas the corner case show above, which will be resolved with more generalmethod in the future. As a result, WARN_ON_ONCE will be triggered. AsAlexei suggested, remove the WARN_ON_ONCE first.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix NULL pointer deference on eir_get_service_dataThe len parameter is considered optional so it can be NULL so it cannotbe used for skipping to next entry of EIR_SERVICE_DATA.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()There is no disagreement that we should check both ptp->is_virtual_clockand ptp->n_vclocks to check if the ptp virtual clock is in use.However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks inptp_vclock_in_use(), we observe a recursive lock in the call tracestarting from n_vclocks_store().============================================WARNING: possible recursive locking detected6.15.0-rc6 #1 Not tainted--------------------------------------------syz.0.1540/13807 is trying to acquire lock:ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415but task is already holding lock:ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK ***....============================================The best way to solve this is to remove the logic that checksptp->n_vclocks in ptp_vclock_in_use().The reason why this is appropriate is that any path that usesptp->n_vclocks must unconditionally check if ptp->n_vclocks is greaterthan 0 before unregistering vclocks, and all functions are alreadywritten this way. And in the function that uses ptp->n_vclocks, wealready get ptp->n_vclocks_mux before unregistering vclocks.Therefore, we need to remove the redundant check for ptp->n_vclocks inptp_vclock_in_use() to prevent recursive locking.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix double-free on mc_devThe blamed commit tried to simplify how the deallocations are done but,in the process, introduced a double-free on the mc_dev variable.In case the MC device is a DPRC, a new mc_bus is allocated and themc_dev variable is just a reference to one of its fields. In thiscircumstance, on the error path only the mc_bus should be freed.This commit introduces back the following checkpatch warning which is afalse-positive.WARNING: kfree(NULL) is safe and this check is probably not required+ if (mc_bus)+ kfree(mc_bus);
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_tableThe function atomctrl_initialize_mc_reg_table() andatomctrl_initialize_mc_reg_table_v2_2() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()fails to retrieve vram_info, it returns NULL which is laterdereferenced.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:aoe: clean device rq_list in aoedev_downdev()An aoe device's rq_list contains accepted block requests that arewaiting to be transmitted to the aoe target. This queue was added aspart of the conversion to blk_mq. However, the queue was not cleaned outwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleepindefinitely waiting for those requests to complete, causing a hang. Thisfix cleans out the queue before calling blk_mq_freeze_queue().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Use memcpy() for BIOS versionThe strlcat() with FORTIFY support is triggering a panic because itthinks the target buffer will overflow although the correct targetbuffer size is passed in.Anyway, instead of memset() with 0 followed by a strlcat(), just usememcpy() and ensure that the resulting buffer is NULL terminated.BIOSVersion is only used for the lpfc_printf_log() which expects aproperly terminated string.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()Since handle->h_transaction may be a NULL pointer, so we should change itto call is_handle_aborted(handle) first before dereferencing it.And the following data-race was reported in my fuzzer:==================================================================BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadatawrite to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....value changed: 0x00000000 -> 0x00000001==================================================================This issue is caused by missing data-race annotation for jh->b_modified.Therefore, the missing annotation needs to be added.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi parse and parseext cache leaksACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5I'm Seunghun Han, and I work for National Security Research Institute ofSouth Korea.I have been doing a research on ACPI and found an ACPI cache leak in ACPIearly abort cases.Boot log of ACPI cache leak is as follows:[ 0.352414] ACPI: Added _OSI(Module Device)[ 0.353182] ACPI: Added _OSI(Processor Device)[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)[ 0.356028] ACPI: Unable to start the ACPI Interpreter[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #10[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.361873] Call Trace:[ 0.362243] ? dump_stack+0x5c/0x81[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27[ 0.363296] ? acpi_os_delete_cache+0xa/0x10[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.364000] ? acpi_terminate+0xa/0x14[ 0.364000] ? acpi_init+0x2af/0x34f[ 0.364000] ? __class_create+0x4c/0x80[ 0.364000] ? video_setup+0x7f/0x7f[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27[ 0.364000] ? do_one_initcall+0x4e/0x1a0[ 0.364000] ? kernel_init_freeable+0x189/0x20a[ 0.364000] ? rest_init+0xc0/0xc0[ 0.364000] ? kernel_init+0xa/0x100[ 0.364000] ? ret_from_fork+0x25/0x30I analyzed this memory leak in detail. I found that "Acpi-State" cache and"Acpi-Parse" cache were merged because the size of cache objects was sameslab cache size.I finally found "Acpi-Parse" cache and "Acpi-parse_ext" cache were leakedusing SLAB_NEVER_MERGE flag in kmem_cache_create() function.Real ACPI cache leak point is as follows:[ 0.360101] ACPI: Added _OSI(Module Device)[ 0.360101] ACPI: Added _OSI(Processor Device)[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)[ 0.364016] ACPI: Unable to start the ACPI Interpreter[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.372000] Call Trace:[ 0.372000] ? dump_stack+0x5c/0x81[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? acpi_os_delete_cache+0xa/0x10[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b[ 0.372000] ? acpi_terminate+0xa/0x14[ 0.372000] ? acpi_init+0x2af/0x34f[ 0.372000] ? __class_create+0x4c/0x80[ 0.372000] ? video_setup+0x7f/0x7f[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? do_one_initcall+0x4e/0x1a0[ 0.372000] ? kernel_init_freeable+0x189/0x20a[ 0.372000] ? rest_init+0xc0/0xc0[ 0.372000] ? kernel_init+0xa/0x100[ 0.372000] ? ret_from_fork+0x25/0x30[ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.392000] Call Trace:[ 0.392000] ? dump_stack+0x5c/0x81[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27[ 0.392000] ? acpi_os_delete_cache+0xa/0x10[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.392000] ? acpi_terminate+0xa/0x14[ 0.392000] ? acpi_init+0x2af/0x3---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check for get_first_active_display()The function mod_hdcp_hdcp1_enable_encryption() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference inmod_hdcp_hdcp2_enable_encryption().Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix a possible null pointer dereferenceIn tegra_crtc_reset(), new memory is allocated with kzalloc(), butno check is performed. Before calling __drm_atomic_helper_crtc_reset,state should be checked to prevent possible null pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before usingRunning IDXD workloads in a container with the /dev directory mounted cantrigger a call trace or even a kernel panic when the parent process of thecontainer is terminated.This issue occurs because, under certain configurations, Docker does notproperly propagate the mount replica back to the original mount point.In this case, when the user driver detaches, the WQ is destroyed but itstill calls destroy_workqueue() attempting to completes all pending work.It's necessary to check wq->wq and skip the drain if it no longer exists.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Disable interrupts before resetting the GPUCurrently, an interrupt can be triggered during a GPU reset, which canlead to GPU hangs and NULL pointer dereference in an interrupt contextas shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---Before resetting the G---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Refuse to evaluate a method if arguments are missingAs reported in [1], a platform firmware update that increased the numberof method parameters and forgot to update a least one of its callers,caused ACPICA to crash due to use-after-free.Since this a result of a clear AML issue that arguably cannot be fixedup by the interpreter (it cannot produce missing data out of thin air),address it by making ACPICA refuse to evaluate a method if the callerattempts to pass fewer arguments than expected to it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix timeline left held on VMA alloc errorThe following error has been reported sporadically by CI when a testunbinds the i915 driver on a ring submission platform:<4> [239.330153] ------------[ cut here ]------------<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330942] Call Trace:<4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915]<4> [239.331202] i915_driver_release+0x86/0xa0 [i915]<4> [239.331482] devm_drm_dev_init_release+0x61/0x90<4> [239.331494] devm_action_release+0x15/0x30<4> [239.331504] release_nodes+0x3d/0x120<4> [239.331517] devres_release_all+0x96/0xd0<4> [239.331533] device_unbind_cleanup+0x12/0x80<4> [239.331543] device_release_driver_internal+0x23a/0x280<4> [239.331550] ? bus_find_device+0xa5/0xe0<4> [239.331563] device_driver_detach+0x14/0x20...<4> [357.719679] ---[ end trace 0000000000000000 ]---If the test also unloads the i915 module then that's followed with:<3> [357.787478] =============================================================================<3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown()<3> [357.788031] -----------------------------------------------------------------------------<3> [357.788204] Object 0xffff888109e7f480 @offset=29824<3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244<4> [357.788994] i915_vma_instance+0xee/0xc10 [i915]<4> [357.789290] init_status_page+0x7b/0x420 [i915]<4> [357.789532] intel_engines_init+0x1d8/0x980 [i915]<4> [357.789772] intel_gt_init+0x175/0x450 [i915]<4> [357.790014] i915_gem_init+0x113/0x340 [i915]<4> [357.790281] i915_driver_probe+0x847/0xed0 [i915]<4> [357.790504] i915_pci_probe+0xe6/0x220 [i915]...Closer analysis of CI results history has revealed a dependency of theerror on a few IGT tests, namely:- igt@api_intel_allocator@fork-simple-stress-signal,- igt@api_intel_allocator@two-level-inception-interruptible,- igt@gem_linear_blits@interruptible,- igt@prime_mmap_coherency@ioctl-errors,which invisibly trigger the issue, then exhibited with first driver unbindattempt.All of the above tests perform actions which are actively interrupted withsignals. Further debugging has allowed to narrow that scope down toDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ringsubmission, in particular.If successful then that function, or its execlists or GuC submissionequivalent, is supposed to be called only once per GEM context engine,followed by raise of a flag that prevents the function from being calledagain. The function is expected to unwind its internal errors itself, soit may be safely called once more after it returns an error.In case of ring submission, the function first gets a reference to theengine's legacy timeline and then allocates a VMA. If the VMA allocationfails, e.g. when i915_vma_instance() called from inside is interruptedwith a signal, then ring_context_alloc() fails, leaving the timeline heldreferenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to thetimeline is got, and only that last one is put on successful completion.As a consequence, the legacy timeline, with its underlying engine statuspage's VMA object, is still held and not released on driver unbind.Get the legacy timeline only after successful allocation of the contextengine's VMA.v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert control queue mutex to a spinlockWith VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generatedon module load:[ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578[ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager[ 324.701689] preempt_count: 201, expected: 0[ 324.701693] RCU nest depth: 0, expected: 0[ 324.701697] 2 locks held by NetworkManager/1582:[ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0[ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870[ 324.701749] Preemption disabled at:[ 324.701752] [] __dev_open+0x3dd/0x870[ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)[ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022[ 324.701774] Call Trace:[ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80[ 324.701788] ? __dev_open+0x3dd/0x870[ 324.701793] __might_resched.cold+0x1ef/0x23d<..>[ 324.701818] __mutex_lock+0x113/0x1b80<..>[ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf][ 324.701935] ? kasan_save_track+0x14/0x30[ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]<..>[ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf][ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf][ 324.702021] ? rcu_is_watching+0x12/0xc0[ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]<..>[ 324.702122] __hw_addr_sync_dev+0x1cf/0x300[ 324.702126] ? find_held_lock+0x32/0x90[ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf][ 324.702152] __dev_open+0x3f8/0x870[ 324.702159] ? __pfx___dev_open+0x10/0x10[ 324.702174] __dev_change_flags+0x443/0x650<..>[ 324.702208] netif_change_flags+0x80/0x160[ 324.702218] do_setlink.isra.0+0x16a0/0x3960<..>[ 324.702349] rtnl_newlink+0x12fd/0x21e0The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock)Fix by converting cq_lock to a spinlock. All operations under the newlock are safe except freeing the DMA memory, which may use vunmap(). Fixby requesting a contiguous physical memory for the DMA mapping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()The function core_scsi3_decode_spec_i_port(), in its error code path,unconditionally calls core_scsi3_lunacl_undepend_item() passing thedest_se_deve pointer, which may be NULL.This can lead to a NULL pointer dereference if dest_se_deve remainsunset.SPC-3 PR SPEC_I_PT: Unable to locate dest_tpgUnable to handle kernel paging request at virtual address dfff800000000012Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]Fix this by adding a NULL check before callingcore_scsi3_lunacl_undepend_item()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix a fence leak in submit error pathIn error paths, we could unref the submit without callingdrm_sched_entity_push_job(), so msm_job_free() will never getcalled. Since drm_sched_job_cleanup() will NULL out thes_fence, we can use that to detect this case.Patchwork: https://patchwork.freedesktop.org/patch/653584/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacksAfter retrieving WMI data blocks in sysfs callbacks, check for thevalidity of them before dereferencing their content.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: do not ping device which has failed to load firmwareSyzkaller reports [1, 2] crashes caused by an attempts to pingthe device which has failed to load firmware. Since such a devicedoesn't pass 'ieee80211_register_hw()', an internal workqueuemanaged by 'ieee80211_queue_work()' is not yet created and anattempt to queue work on it causes null-ptr-deref.[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix sample vs do_exit()Baisheng Gao reported an ARM64 crash, which Mark decoded as being asynchronous external abort -- most likely due to trying to accessMMIO in bad ways.The crash further shows perf trying to do a user stack sample while inexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the addressspace it is trying to access.It turns out that we stop perf after we tear down the userspace mm; areceipie for disaster, since perf likes to access userspace forvarious reasons.Flip this order by moving up where we stop perf in do_exit().Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USERto abort when the current task does not have an mm (exit_mm() makessure to set current->mm = NULL; before commencing with the actualteardown). Such that CPU wide events don't trip on this same problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Add basic validation for RAS headerIf RAS header read from EEPROM is corrupted, it could result in tryingto allocate huge memory for reading the records. Add some validation toheader fields.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: nfsd4_spo_must_allow() must check this is a v4 compound requestIf the request being processed is not a v4 compound request, thenexamining the cstate can have undefined results.This patch adds a check that the rpc procedure being executed(rq_procinfo) is the NFSPROC4_COMPOUND procedure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.sof_pdata->tplg_filename can have address allocated by kstrdup()and can be overwritten. Memory leak was detected with kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Abort __tc_modify_qdisc if parent class does not existLion's patch [1] revealed an ancient bug in the qdisc API.Whenever a user creates/modifies a qdisc specifying as a parent anotherqdisc, the qdisc API will, during grafting, detect that the user isnot trying to attach to a class and reject. However grafting isperformed after qdisc_create (and thus the qdiscs' init callback) isexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlogduring init or change (such as fq, hhf, choke, etc), an issuearises. For example, executing the following commands:sudo tc qdisc add dev lo root handle a: htb default 2sudo tc qdisc add dev lo parent a: handle beef fqQdiscs such as fq, hhf, choke, etc unconditionally invokeqdisc_tree_reduce_backlog() in their control path init() or change() whichthen causes a failure to find the child class; however, that does not stopthe unconditional invocation of the assumed child qdisc's qlen_notify witha null class. All these qdiscs make the assumption that class is non-null.The solution is ensure that qdisc_leaf() which looks up the parentclass, and is invoked prior to qdisc_create(), should return failure onnot finding the class.In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever theparentid doesn't correspond to a class, so that we can detect itearlier on and abort before qdisc_create is called.[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtimeAssuming the "rx-vlan-filter" feature is enabled on a net device, the8021q module will automatically add or remove VLAN 0 when the net deviceis put administratively up or down, respectively. There are a couple ofproblems with the above scheme.The first problem is a memory leak that can happen if the "rx-vlan-filter"feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1When the device is put administratively down the "rx-vlan-filter"feature is disabled, so the 8021q module will not remove VLAN 0 and thememory will be leaked [1].Another problem that can happen is that the kernel can automaticallydelete VLAN 0 when the device is put administratively down despite notadding it when the device was put administratively up since during thattime the "rx-vlan-filter" feature was disabled. null-ptr-unref orbug_on[2] will be triggered by unregister_vlan_dev() for refcountimbalance if toggling filtering during runtime:$ ip link add bond0 type bond mode 0$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q$ ethtool -K bond0 rx-vlan-filter off$ ifconfig bond0 up$ ethtool -K bond0 rx-vlan-filter on$ ifconfig bond0 down$ ip link del vlan0Root cause is as below:step1: add vlan0 for real_dev, such as bond, team.register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1step2: disable vlan filter feature and enable real_devstep3: change filter from 0 to 1vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0step4: real_dev downvlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0step5: delete vlan0unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is nullFix both problems by noting in the VLAN info whether VLAN 0 wasautomatically added upon NETDEV_UP and based on that decide whether itshould be deleted upon NETDEV_DOWN, regardless of the state of the"rx-vlan-filter" feature.[1]unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180[2]kernel BUG at net/8021q/vlan.c:99!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))RSP: 0018:ffff88810badf310 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9aRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017eFS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0Call Trace:
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: net: sierra: check for no status endpointThe driver checks for having three endpoints andhaving bulk in and out endpoints, but not thatthe third endpoint is interrupt input.Rectify the omission.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: lpc-snoop: Don't disable channels that aren't enabledMitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: canaan: k230: add NULL check in DT parseAdd a NULL check for the return value of of_get_property() whenretrieving the "pinmux" property in the group parser. This avoidsa potential NULL pointer dereference if the property is missingfrom the device tree node.Also fix a typo ("sintenel") in the device ID match table comment,correcting it to "sentinel".
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entryWhen UFFDIO_MOVE encounters a migration PMD entry, it proceeds withobtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check.[surenb@google.com: remove extra folio check, per David]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hibmcge: fix the division by zero issueWhen the network port is down, the queue is released, and ring->len is 0.In debugfs, hbg_get_queue_used_num() will be called,which may lead to a division by zero issue.This patch adds a check, if ring->len is 0,hbg_get_queue_used_num() directly returns 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ftgmac100: fix potential NULL pointer access in ftgmac100_phy_disconnectAfter the call to phy_disconnect() netdev->phydev is reset to NULL.So fixed_phy_unregister() would be called with a NULL pointer as argument.Therefore cache the phy_device before this call.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Do not map lowcore with identity mappingSince the identity mapping is pinned to address zero the lowcore is alwaysalso mapped to address zero, this happens regardless of the relocate_lowcorecommand line option. If the option is specified the lowcore is mappedtwice, instead of only once.This means that NULL pointer accesses will succeed instead of causing anexception (low address protection still applies, but covers only parts).To fix this never map the first two pages of physical memory with theidentity mapping.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xferThe data->block[0] variable comes from user. Without proper check,the variable may be very large to cause an out-of-bounds bug.Fix this bug by checking the value of data->block[0] first.1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in ismt_access()")2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: KVM: Fix stack protector issue in send_ipi_data()Function kvm_io_bus_read() is called in function send_ipi_data(), buffersize of parameter *val should be at least 8 bytes. Since some emulationfunctions like loongarch_ipi_readl() and kvm_eiointc_read() will writethe buffer *val with 8 bytes signed extension regardless parameter len.Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTORis enabled. The bug report is shown as follows:Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ...Call Trace:[<9000000003af3734>] show_stack+0x5c/0x180[<9000000003aed168>] dump_stack_lvl+0x6c/0x9c[<9000000003ad0ab0>] vpanic+0x108/0x2c4[<9000000003ad0ca8>] panic+0x3c/0x40[<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18[] send_ipi_data+0x190/0x1a0 [kvm][] __kvm_io_bus_write+0xa4/0xe8 [kvm][] kvm_io_bus_write+0x54/0x90 [kvm][] kvm_emu_iocsr+0x180/0x310 [kvm][] kvm_handle_gspr+0x280/0x478 [kvm][] kvm_handle_exit+0xc0/0x130 [kvm]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() callsBoth the ACE and CSI driver are missing a mei_cldev_disable() call intheir remove() function.This causes the mei_cl client to stay part of the mei_device->file_listlist even though its memory is freed by mei_cl_bus_dev_release() callingkfree(cldev->cl).This leads to a use-after-free when mei_vsc_remove() runs mei_stop()which first removes all mei bus devices calling mei_ace_remove() andmei_csi_remove() followed by mei_cl_bus_dev_release() and then callsmei_cl_all_disconnect() which walks over mei_device->file_list dereferecingthe just freed cldev->cl.And mei_vsc_remove() it self is run at shutdown because of theplatform_device_unregister(tp->pdev) in vsc_tp_shutdown()When building a kernel with KASAN this leads to the following KASAN report:[ 106.634504] ==================================================================[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1[ 106.634729][ 106.634767] Tainted: [E]=UNSIGNED_MODULE[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025[ 106.634773] Call Trace:[ 106.634777] ...[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei...[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc[ 106.635066] platform_remove (drivers/base/platform.c:1424)Add the missing mei_cldev_disable() calls so that the mei_cl gets removedfrom mei_device->file_list before it is freed to fix this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mt9m114: Fix deadlock in get_frame_interval/set_frame_intervalGetting / Setting the frame interval using the V4L2 subdev pad opsget_frame_interval/set_frame_interval causes a deadlock, as thesubdev state is locked in the [1] but also in the driver itself.In [2] it's described that the caller is responsible to acquire andrelease the lock in this case. Therefore, acquiring the lock in thedriver is wrong.Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()and mt9m114_ifp_set_frame_interval().[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129[2] Documentation/driver-api/media/v4l2-subdev.rst
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULPSince the CAAM on these SoCs is managed by another ARM core, called theSECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, whichalso reserves access to register page 0 suspend operations cannot touchthis page.This is similar to when running OPTEE, where OPTEE will reserve page 0.Track this situation using a new state variable no_page0, reflecting ifpage 0 is reserved elsewhere, either by other management cores in SoC orby OPTEE.Replace the optee_en check in suspend/resume with the new check.optee_en cannot go away as it's needed elsewhere to gate OPTEE specificsituations.Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfs: Fix unbuffered write error handlingIf all the subrequests in an unbuffered write stream fail, the subrequestcollector doesn't update the stream->transferred value and it retains itsinitial LONG_MAX value. Unfortunately, if all active streams fail, then wetake the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to setin wreq->transferred - which is then returned from ->write_iter().LONG_MAX was chosen as the initial value so that all the streams can bequickly assessed by taking the smallest value of all stream->transferred -but this only works if we've set any of them.Fix this by adding a flag to indicate whether the value instream->transferred is valid and checking that when we integrate thevalues. stream->transferred can then be initialised to zero.This was found by running the generic/750 xfstest against cifs withcache=none. It splices data to the target file. Once (if) it has used upall the available scratch space, the writes start failing with ENOSPC.This causes ->write_iter() to fail. However, it was returningwreq->transferred, i.e. LONG_MAX, rather than an error (because it thoughtthe amount transferred was non-zero) and iter_file_splice_write() wouldthen try to clean up that amount of pipe bufferage - leading to an oopswhen it overran. The kernel log showed: CIFS: VFS: Send error in write = -28followed by: BUG: kernel NULL pointer dereference, address: 0000000000000008with: RIP: 0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0or: RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755)Also put a warning check into splice to announce if ->write_iter() returnedthat it had written more than it was asked to.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: samsung: Fix UBSAN panic in samsung_clk_init()With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due todereferencing `ctx->clk_data.hws` before setting`ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: fix ida_free call while not allocatedIn the snd_utimer_create() function, if the kasprintf() function returnNULL, snd_utimer_put_id() will be called, finally use ida_free()to free the unallocated id 0.the syzkaller reported the following information: ------------[ cut here ]------------ ida_free called for id=0 which is not allocated. WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 Modules linked in: CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592 Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...) RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5 RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200 RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0 Call Trace: snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer] snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer] snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer] __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer] 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+0x198/0x200 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...]The utimer->id should be set properly before the kasprintf() function,ensures the snd_utimer_put_id() function will free the allocated id.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: Optimize module load time by optimizing PLT/GOT countingWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD andCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,the relevant logs are as follows:rcu: INFO: rcu_sched self-detected stall on CPU...Call Trace:[<900000000024f9e4>] show_stack+0x5c/0x180[<90000000002482f4>] dump_stack_lvl+0x94/0xbc[<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280[<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88[<9000000000396c34>] update_process_times+0xb4/0x150[<90000000003b2474>] tick_nohz_handler+0xf4/0x250[<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428[<9000000000399b2c>] hrtimer_interrupt+0x214/0x538[<9000000000253634>] constant_timer_interrupt+0x64/0x80[<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0[<9000000000349a78>] handle_irq_event_percpu+0x18/0x88[<9000000000354c00>] handle_percpu_irq+0x90/0xf0[<9000000000348c74>] handle_irq_desc+0x94/0xb8[<9000000001012b28>] handle_cpu_irq+0x68/0xa0[<9000000001def8c0>] handle_loongarch_irq+0x30/0x48[<9000000001def958>] do_vint+0x80/0xd0[<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0[<90000000006344f4>] __asan_load8+0x4c/0x120[<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8[<90000000003895f0>] load_module+0x9e0/0x2958[<900000000038b770>] __do_sys_init_module+0x208/0x2d0[<9000000001df0c34>] do_syscall+0x94/0x190[<900000000024d6fc>] handle_syscall+0xbc/0x158After analysis, this is because the slow speed of loading the amdgpumodule leads to the long time occupation of the cpu and then the softdeadlock.When loading a module, module_frob_arch_sections() tries to figure outthe number of PLTs/GOTs that will be needed to handle all the RELAs. Itwill call the count_max_entries() to find in an out-of-order date whichcounting algorithm has O(n^2) complexity.To make it faster, we sort the relocation list by info and addend. Thatway, to check for a duplicate relocation, it just needs to compare withthe previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize moduleload time by optimizing PLT counting"). This gives sinificant reductionin module load time for modules with large number of relocations.After applying this patch, the soft deadlock problem has been solved,and the kernel starts normally without "Call Trace".Using the default configuration to test some modules, the results are asfollows:Module Sizeip_tables 36Kfat 143Kradeon 2.5MBamdgpu 16MBWithout this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 54 1221/84amdgpu 1411 4525/1098With this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 22 1221/84amdgpu 45 4525/1098
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #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:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 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:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let's call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won't see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/ext: Fix invalid task state transitions on class switchWhen enabling a sched_ext scheduler, we may trigger invalid task statetransitions, resulting in warnings like the following (which can beeasily reproduced by running the hotplug selftest in a loop): sched_ext: Invalid task state transition 0 -> 3 for fish[770] WARNING: CPU: 18 PID: 787 at kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 ... RIP: 0010:scx_set_task_state+0x7c/0xc0 ... Call Trace: scx_enable_task+0x11f/0x2e0 switching_to_scx+0x24/0x110 scx_enable.isra.0+0xd14/0x13d0 bpf_struct_ops_link_create+0x136/0x1a0 __sys_bpf+0x1edd/0x2c30 __x64_sys_bpf+0x21/0x30 do_syscall_64+0xbb/0x370 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis happens because we skip initialization for tasks that are alreadydead (with their usage counter set to zero), but we don't exclude themduring the scheduling class transition phase.Fix this by also skipping dead tasks during class swiching, preventinginvalid task state transitions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid possible overflow for chunk_sectors check in blk_stack_limits()In blk_stack_limits(), we check that the t->chunk_sectors value is amultiple of the t->physical_block_size value.However, by finding the chunk_sectors value in bytes, we may overflowthe unsigned int which holds chunk_sectors, so change the check to bebased on sectors.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl()The UIC completion interrupt may be disabled while an UIC command isbeing processed. When the UIC completion interrupt is reenabled, an UICinterrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit.Hence this patch that removes this kernel warning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengthsSince the buffers are mapped from userspace, it is prudent to useREAD_ONCE() to read the value into a local variable, and use that forany other actions taken. Having a stable read of the buffer lengthavoids worrying about it changing after checking, or being read multipletimes.Similarly, the buffer may well change in between it being picked andbeing committed. Ensure the looping for incremental ring buffer commitstops if it hits a zero sized buffer, as no further progress can be madeat that point.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: fix signedness in this_len calculationWhen importing and using buffers, buf->len is considered unsigned.However, buf->len is converted to signed int when committing. This canlead to unexpected behavior if the buffer is large enough to beinterpreted as a negative value. Make min_t calculation unsigned.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error pathIn the error path of hws_pool_buddy_init(), the buddy allocator cleanupdoesn't free the allocator structure itself, causing a memory leak.Add the missing kfree() to properly release all allocated memory.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbnic: Move phylink resume out of service_task and into open/closeThe fbnic driver was presenting with the following locking assert comingout of a PM resume:[ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611)[ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0[ 42.208872][ T164] Modules linked in:[ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full)[ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014[ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0[ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef[ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296[ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000[ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001[ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84[ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000[ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0[ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000[ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0[ 42.213227][ T164] PKRU: 55555554[ 42.213366][ T164] Call Trace:[ 42.213483][ T164] [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0[ 42.213725][ T164] pci_reset_function+0x116/0x1d0[ 42.213895][ T164] reset_store+0xa0/0x100[ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50[ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0[ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160[ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0[ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0[ 42.214836][ T164] new_sync_write+0x308/0x6f0[ 42.214987][ T164] ? __lock_acquire+0x34c/0x740[ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0[ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260[ 42.215440][ T164] ? ksys_write+0xff/0x200[ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0[ 42.215742][ T164] vfs_write+0x65e/0xbb0[ 42.215876][ T164] ksys_write+0xff/0x200[ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0[ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0[ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0[ 42.216442][ T164] do_syscall_64+0xbb/0x360[ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53[ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986A bit of digging showed that we were invoking the phylink_resume as a partof the fbnic_up path when we were enabling the service task while notholding the RTNL lock. We should be enabling this sooner as a part of thendo_open path and then just letting the service task come online later.This will help to enforce the correct locking and brings the phylinkinterface online at the same time as the network interface, instead of at alater time.I tested this on QEMU to verify this was working by putting the system tosleep using "echo mem > /sys/power/state" to put the system to sleep in theguest and then using the command "system_wakeup" in the QEMU monitor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flowWhen an invalid stc_type is provided, the function allocates memory forshared_stc but jumps to unlock_and_out without freeing it, causing amemory leak.Fix by jumping to free_shared_stc label instead to ensure proper cleanup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: slub: avoid wake up kswapd in set_track_prepareset_track_prepare() can incur lock recursion.The issue is that it is called from hrtimer_start_range_nsholding the per_cpu(hrtimer_bases)[n].lock, but when enabledCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,and try to hold the per_cpu(hrtimer_bases)[n].lock.Avoid deadlock caused by implicitly waking up kswapd by passing inallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in thedebug_objects_fill_pool() case. Inside stack depot they are processed bygfp_nested_mask().Since ___slab_alloc() has preemption disabled, we mask out__GFP_DIRECT_RECLAIM from the flags there.The oops looks something like:BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)Call trace:spin_bug+0x0_raw_spin_lock_irqsave+0x80hrtimer_try_to_cancel+0x94task_contending+0x10cenqueue_dl_entity+0x2a4dl_server_start+0x74enqueue_task_fair+0x568enqueue_task+0xacdo_activate_task+0x14cttwu_do_activate+0xcctry_to_wake_up+0x6c8default_wake_function+0x20autoremove_wake_function+0x1c__wake_up+0xacwakeup_kswapd+0x19cwake_all_kswapds+0x78__alloc_pages_slowpath+0x1ac__alloc_pages_noprof+0x298stack_depot_save_flags+0x6b0stack_depot_save+0x14set_track_prepare+0x5c___slab_alloc+0xccc__kmalloc_cache_noprof+0x470__set_page_owner+0x2bcpost_alloc_hook[jt]+0x1b8prep_new_page+0x28get_page_from_freelist+0x1edc__alloc_pages_noprof+0x13calloc_slab_page+0x244allocate_slab+0x7c___slab_alloc+0x8e8kmem_cache_alloc_noprof+0x450debug_objects_fill_pool+0x22cdebug_object_activate+0x40enqueue_hrtimer[jt]+0xdchrtimer_start_range_ns+0x5f8...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it justexits the function. This ends up causing a memory-leak:unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), whenexiting upon error, inet_csk_prepare_forced_close() and tcp_done() needto be called. They make sure the newsk will end up being correctlyfree'd.tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exitlabel that takes care of things. So, this patch here makes suretcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similarerror-handling and thus fixes the leak for TCP-AO.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix invalid accesses to ceph_connection_v1_infoThere is a place where generic code in messenger.c is reading andanother place where it is writing to con->v1 union member withoutchecking that the union member is active (i.e. msgr1 is in use).On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,so such a read is almost guaranteed to return a bogus value instead of0 when msgr2 is in use. This ends up being fairly benign because theside effect is just the invalidation of the authorizer and successivefetching of new tickets.con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact thatit's being written to can cause more serious consequences, but luckilyit's not something that happens often.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memoryWhen I did memory failure tests, below panic occurs:page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))kernel BUG at include/linux/page-flags.h:616!Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Call Trace:
unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f08f0314887RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffffR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject---[ end trace 0000000000000000 ]---RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Kernel panic - not syncing: Fatal exceptionKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)---[ end Kernel panic - not syncing: Fatal exception ]---The root cause is that unpoison_memory() tries to check the PG_HWPoisonflags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) istriggered. This can be reproduced by below steps:1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state2.Get offlined memory pfn: page-types -b n -rlN3.Write pfn to unpoison-pfn echo
> /sys/kernel/debug/hwpoison/unpoison-pfnThis scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail ifpfn_to_online_page() == NULL to fix the bug.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix subvolume deletion lockup caused by inodes xarray raceThere is a race condition between inode eviction and inode caching thatcan cause a live struct btrfs_inode to be missing from the root->inodesxarray. Specifically, there is a window during evict() between the inodebeing unhashed and deleted from the xarray. If btrfs_iget() is calledfor the same inode in that window, it will be recreated and insertedinto the xarray, but then eviction will delete the new entry, leavingnothing in the xarray:Thread 1 Thread 2---------------------------------------------------------------evict() remove_inode_hash() btrfs_iget_path() btrfs_iget_locked() btrfs_read_locked_inode() btrfs_add_inode_to_root() destroy_inode() btrfs_destroy_inode() btrfs_del_inode_from_root() __xa_eraseIn turn, this can cause issues for subvolume deletion. Specifically, ifan inode is in this lost state, and all other inodes are evicted, thenbtrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.If the lost inode has a delayed_node attached to it, then whenbtrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),it will loop forever because the delayed_nodes xarray will never becomeempty (unless memory pressure forces the inode out). We saw thismanifest as soft lockups in production.Fix it by only deleting the xarray entry if it matches the given inode(using __xa_cmpxchg()).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() cancause various locking issues; see the following stack trace (edited forstyle) as one example:... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock...The above was reproduced on bpf-next (b338cf849ec8) by modifying./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() duringops.runnable(), and hacking the memcg accounting code a bit to makea bpf_timer_init() call more likely to raise an MEMCG_MAX event.We have also run into other similar variants (both internally and onbpf-next), including double-acquiring cgroup_file_kn_lock, the sameworker_pool::lock, etc.As suggested by Shakeel, fix this by using __GFP_HIGH instead ofGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()raises an MEMCG_MAX event, we call __memcg_memory_event() with@allow_spinning=false and avoid calling cgroup_file_notify() there.Depends on mm patch"memcg: skip cgroup_file_notify if spinning is not allowed":https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/v1 approach:https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask andalways allocate memory using the hardcoded GFP_KERNEL flag. This makesthem inconsistent with vmalloc(), which was recently extended to supportGFP_NOFS and GFP_NOIO allocations.Page table allocations performed during shadow population also ignore theexternal gfp_mask. To preserve the intended semantics of GFP_NOFS andGFP_NOIO, wrap the apply_to_page_range() calls into the appropriatememalloc scope.xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.There was a report herehttps://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.comThis patch: - Extends kasan_populate_vmalloc() and helpers to take gfp_mask; - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page(); - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore() around apply_to_page_range(); - Updates vmalloc.c and percpu allocator call sites accordingly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.syzbot reported the splat below. [0]The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytesAt 5., the data is carried over to the next sendmsg() as it issmaller than the cork_bytes specified by bpf_msg_cork_bytes().Then, tcp_bpf_send_verdict() tries to allocate psock->cork to holdthe data, but this fails silently due to fault injection + __GFP_NOWARN.If the allocation fails, we need to revert the sk->sk_forward_allocchange done by sk_msg_alloc().Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocatepsock->cork.The "*copied" also needs to be updated such that a proper error canbe returned to the caller, sendmsg. It fails to allocate psock->cork.Nothing has been corked so far, so this patch simply sets "*copied"to 0.[0]:WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983Modules linked in:CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fcRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded()The sma1307->set.header_size is how many integers are in the header(there are 8 of them) but instead of allocating space of 8 integerswe allocate 8 bytes. This leads to memory corruption when we copy datait on the next line: memcpy(sma1307->set.header, data, sma1307->set.header_size * sizeof(int));Also since we're immediately copying over the memory in ->set.header,there is no need to zero it in the allocator. Use devm_kmalloc_array()to allocate the memory instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: Update napi->skb after XDP processThe syzbot report a UAF issue: BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline] BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline] BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079 CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 skb_reset_mac_header include/linux/skbuff.h:3150 [inline] napi_frags_skb net/core/gro.c:723 [inline] napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 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/0x7f Allocated by task 6079: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:330 [inline] __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558 kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline] napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295 __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657 napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811 napi_get_frags+0x69/0x140 net/core/gro.c:673 tun_napi_alloc_frags drivers/net/tun.c:1404 [inline] tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 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/0x7f Freed by task 6079: 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:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2422 [inline] slab_free mm/slub.c:4695 [inline] kmem_cache_free+0x18f/0x400 mm/slub.c:4797 skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969 netif_skb_check_for_xdp net/core/dev.c:5390 [inline] netif_receive_generic_xdp net/core/dev.c:5431 [inline] do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499 tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 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/0x7fAfter commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running ingeneric mode"), the original skb may be freed in skb_pp_cow_data() whenXDP program was attached, which was allocated in tun_napi_alloc_frags().However, the napi->skb still point to the original skb, update it afterXDP process.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: use is_copy_from_user() to determine copy-from-user contextPatch series "mm/hwpoison: Fix regressions in memory failure handling",v4.## 1. What am I trying to do:This patchset resolves two critical regressions related to memory failurehandling that have appeared in the upstream kernel since version 5.17, ascompared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space## 2. What is the expected outcome and why- For copyin case:Kernel can recover from poison found where kernel is doing get_user() orcopy_from_user() if those places get an error return and the kernel return-EFAULT to the process instead of crashing. More specifily, MCE handlerchecks the fixup handler type to decide whether an in kernel #MC can berecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery codespecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.- For instr case:If a poison found while instruction fetching in user space, full recoveryis possible. User process takes #PF, Linux allocates a new page and fillsby reading from storage.## 3. What actually happens and why- For copyin case: kernel panic since v5.17Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a newextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated theextable fixup type for copy-from-user operations, changing it fromEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESShandling when posion found in get_user() or copy_from_user().- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE raceWhen an uncorrected memory error is consumed there is a race between theCMCI from the memory controller reporting an uncorrected error with a UCNAsignature, and the core reporting and SRAR signature machine check whenthe data is about to be consumed.### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]Prior to Icelake memory controllers reported patrol scrub events thatdetected a previously unseen uncorrected error in memory by signaling abroadcast machine check with an SRAO (Software Recoverable ActionOptional) signature in the machine check bank. This was overkill becauseit's not an urgent problem that no core is on the verge of consuming thatbad data. It's also found that multi SRAO UCE may cause nested MCEinterrupts and finally become an IERR.Hence, Intel downgrades the machine check bank signature of patrol scrubfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to#CMCI. Just to add to the confusion, Linux does take an action (inuc_decode_notifier()) to try to offline the page despite the UC*NA*signature name.### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]Having decided that CMCI/UCNA is the best action for patrol scrub errors,the memory controller uses it for reads too. But the memory controller isexecuting asynchronously from the core, and can't tell the differencebetween a "real" read and a speculative read. So it will do CMCI/UCNA ifan error is found in any read.Thus:1) Core is clever and thinks address A is needed soon, issues a speculative read.2) Core finds it is going to use address A soon after sending the read request3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.Quite often (because speculation has got better) the CMCI from the memorycontroller is delivered before the core is committed to the instructionreading address A, so the interrupt is taken, and Linux offlines the page(marking it as poison).## Why user process is killed for instr caseCommit 046545a661af ("mm/hwpoison: fix error page recovered but reported"not---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: check for stable address space before operating on the VMAIt is possible to hit a zero entry while traversing the vmas in unuse_mm()called from swapoff path and accessing it causes the OOPS:Unable to handle kernel NULL pointer dereference at virtual address0000000000000446--> Loading the memory from offset 0x40 on theXA_ZERO_ENTRY as address.Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation faultThe issue is manifested from the below race between the fork() on aprocess and swapoff:fork(dup_mmap()) swapoff(unuse_mm)--------------- -----------------1) Identical mtree is built using __mt_dup().2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation.3) Fatal signal is sent to the parentprocess(which is the current during thefork) thus skip the duplication of thevmas and mark the vma range withXA_ZERO_ENTRY as a marker for this processthat helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops.The proper fix would be around not exposing this partially-valid tree toothers when droping the mmap lock, which is being solved with [1]. Asimpler solution would be checking for MMF_UNSTABLE, as it is set ifmm_struct is not fully initialized in dup_mmap().Thanks to Liam/Lorenzo/David for all the suggestions in fixing thisissue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.130.3 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix missing pointer check in hda_component_manager_init functionThe __component_match_add function may assign the 'matchptr' pointerthe value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.The call stack leading to the error looks like this:hda_component_manager_init|-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign|-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereferenceAdd IS_ERR() check to prevent the crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: Fix use-after-free in hdm_disconnecthdm_disconnect() calls most_deregister_interface(), which eventuallyunregisters the MOST interface device with device_unregister(iface->dev).If that drops the last reference, the device core may call release_mdev()immediately while hdm_disconnect() is still executing.The old code also freed several mdev-owned allocations inhdm_disconnect() and then performed additional put_device() calls.Depending on refcount order, this could lead to use-after-free ordouble-free when release_mdev() ran (or when unregister paths alsoperformed puts).Fix by moving the frees of mdev-owned allocations into release_mdev(),so they happen exactly once when the device is truly released, and bydropping the extra put_device() calls in hdm_disconnect() that areredundant after device_unregister() and most_deregister_interface().This addresses the KASAN slab-use-after-free reported by syzbot inhdm_disconnect(). See report and stack traces in the bug link below.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: rate: Unset parent pointer in devl_rate_nodes_destroyThe function devl_rate_nodes_destroy is documented to "Unset parent forall rate objects". However, it was only calling the driver-specific`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementingthe parent's refcount, without actually setting the`devlink_rate->parent` pointer to NULL.This leaves a dangling pointer in the `devlink_rate` struct, which causerefcount error in netdevsim[1] and mlx5[2]. In addition, this isinconsistent with the behavior of `devlink_nl_rate_parent_node_set`,where the parent pointer is correctly cleared.This patch fixes the issue by explicitly setting `devlink_rate->parent`to NULL after notifying the driver, thus fulfilling the function'sdocumented behavior for all rate objects.[1]repro steps:echo 1 > /sys/bus/netdevsim/new_devicedevlink dev eswitch set netdevsim/netdevsim1 mode switchdevecho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfsdevlink port function rate add netdevsim/netdevsim1/test_nodedevlink port function rate set netdevsim/netdevsim1/128 parent test_nodeecho 1 > /sys/bus/netdevsim/del_devicedmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2]devlink dev eswitch set pci/0000:08:00.0 mode switchdevdevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000devlink port function rate add pci/0000:08:00.0/group1devlink port function rate set pci/0000:08:00.0/32768 parent group1modprobe -r mlx5_ib mlx5_fwctl mlx5_coredmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: remove never-working support for setting nsh fieldsThe validation of the set(nsh(...)) action is completely wrong.It runs through the nsh_key_put_from_nlattr() function that is thesame function that validates NSH keys for the flow match and thepush_nsh() action. However, the set(nsh(...)) has a very differentmemory layout. Nested attributes in there are doubled in size incase of the masked set(). That makes proper validation impossible.There is also confusion in the code between the 'masked' flag, thatsays that the nested attributes are doubled in size containing boththe value and the mask, and the 'is_mask' that says that the valuewe're parsing is the mask. This is causing kernel crash on trying towrite into mask part of the match with SW_FLOW_KEY_PUT() duringvalidation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe third issue with this process is that while trying to convertthe non-masked set into masked one, validate_set() copies and doublesthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nestedattributes. It should be copying each nested attribute and doublingthem in size independently. And the process must be properly reversedduring the conversion back from masked to a non-masked variant duringthe flow dump.In the end, the only two outcomes of trying to use this action areeither validation failure or a kernel crash. And if somehow someonemanages to install a flow with such an action, it will most definitelynot do what it is supposed to, since all the keys and the masks aremixed up.Fixing all the issues is a complex task as it requires re-writingmost of the validation code.Given that and the fact that this functionality never worked sinceintroduction, let's just remove it altogether. It's better tore-introduce it later with a proper implementation instead of tryingto fix it in stable releases.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix a race in mptcp_pm_del_add_timer()mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)while another might have free entry already, as reported by syzbot.Add RCU protection to fix this issue.Also change confusing add_timer variable with stop_timer boolean.syzbot report:BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Workqueue: events mptcp_workerCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: imx_sc_key - fix memory corruption on unloadThis is supposed to be "priv" but we accidentally pass "&priv" which isan address in the stack and so it will lead to memory corruption whenthe imx_sc_key_action() function is called. Remove the &.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: cros_ec_keyb - fix an invalid memory accessIf cros_ec_keyb_register_matrix() isn't called (due to`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remainsNULL. An invalid memory access is observed in cros_ec_keyb_process()when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_threadIt's still unknown about why the kernel receives such malformed event,in any cases, the kernel shouldn't access `ckdev->idev` and friends ifthe driver doesn't intend to initialize them.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential overflow of PCM transfer bufferThe PCM stream data in USB-audio driver is transferred over USB URBpacket buffers, and each packet size is determined dynamically. Thepacket sizes are limited by some factors such as wMaxPacketSize USBdescriptor. OTOH, in the current code, the actually used packet sizesare determined only by the rate and the PPS, which may be bigger thanthe size limit above. This results in a buffer overflow, as reportedby syzbot.Basically when the limit is smaller than the calculated packet size,it implies that something is wrong, most likely a weird USBdescriptor. So the best option would be just to return an error atthe parameter setup time before doing any further operations.This patch introduces such a sanity check, and returns -EINVAL whenthe packet size is greater than maxpacksize. The comparison withep->packsize[1] alone should suffice since it's always equal orgreater than ep->packsize[0].
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix use-after-free race in fault handlerWhen a page fault occurs in a secret memory file created with`memfd_secret(2)`, the kernel will allocate a new folio for it, mark theunderlying page as not-present in the direct map, and add it to the filemapping.If two tasks cause a fault in the same page concurrently, both could endup allocating a folio and removing the page from the direct map, but onlyone would succeed in adding the folio to the file mapping. The task thatfailed undoes the effects of its attempt by (a) freeing the folio againand (b) putting the page back into the direct map. However, by doingthese two operations in this order, the page becomes available to theallocator again before it is placed back in the direct mapping.If another task attempts to allocate the page between (a) and (b), and thekernel tries to access it via the direct map, it would result in asupervisor not-present page fault.Fix the ordering to restore the direct map before the folio is freed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: free copynotify stateid in nfs4_free_ol_stateid()Typically copynotify stateid is freed either when parent's stateidis being close/freed or in nfsd4_laundromat if the stateid hasn'tbeen used in a lease period.However, in case when the server got an OPEN (which createda parent stateid), followed by a COPY_NOTIFY using that stateid,followed by a client reboot. New client instance while doingCREATE_SESSION would force expire previous state of this client.It leads to the open state being freed thru release_openowner->nfs4_free_ol_stateid() and it finds that it still has copynotifystateid associated with it. We currently print a warning and istriggerredWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]This patch, instead, frees the associated copynotify stateid here.If the parent stateid is freed (without freeing the copynotifystateids associated with it), it leads to the list corruptionwhen laundromat ends up freeing the copynotify state later.[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd][ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200[ 1626.861182] sp : ffff8000881d7a40[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d[ 1626.868167] Call trace:[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd][ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd][ 1626.869813] laundromat_main+0x24/0x60 [nfsd][ 1626.870231] process_one_work+0x584/0x1050[ 1626.870595] worker_thread+0x4c4/0xc60[ 1626.870893] kthread+0x2f8/0x398[ 1626.871146] ret_from_fork+0x10/0x20[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)[ 1626.871892] SMP: stopping secondary CPUs
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_baddIn snd_usb_create_streams(), for UAC version 3 devices, the InterfaceAssociation Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If thiscall fails, a fallback routine attempts to obtain the IAD from the nextinterface and sets a BADD profile. However, snd_usb_mixer_controls_badd()assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,without performing a NULL check. This can lead to a NULL pointerdereference when usb_ifnum_to_if() fails to find the interface descriptor.This patch adds a NULL pointer check after calling usb_ifnum_to_if() insnd_usb_mixer_controls_badd() to prevent the dereference.This issue was discovered by syzkaller, which triggered the bug by sendinga crafted USB device descriptor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZEThis data originates from userspace and is used in buffer offsetcalculations which could potentially overflow causing an out-of-boundsaccess.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix improper check of dentry.stream.valid_sizeWe found an infinite loop bug in the exFAT file system that can lead to aDenial-of-Service (DoS) condition. When a dentry in an exFAT filesystem ismalformed, the following system calls - SYS_openat, SYS_ftruncate, andSYS_pwrite64 - can cause the kernel to hang.Root cause analysis shows that the size validation code in exfat_find()does not check whether dentry.stream.valid_size is negative. As a result,the system calls mentioned above can succeed and eventually trigger the DoSissue.This patch adds a check for negative dentry.stream.valid_size to preventthis vulnerability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devicesPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The rootcause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,but that `man->bdev` (the backing device pointer within the manager) remainsuninitialized (NULL) on APUs-since APUs lack dedicated VRAM and do not fullyset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts toacquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading toa kernel OOPS.1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately-skipping VRAM-specific logic that would trigger the NULL dereference.2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL.3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report).This approach is more robust than APU-specific checks because it:- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),- Aligns with TTM's design by using its native helper function,- Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check).v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-boundsAdd bounds checking to prevent writes past framebuffer boundaries whenrendering text near screen edges. Return early if the Y position is off-screenand clip image height to screen boundary. Break from the rendering loop if theX position is off-screen. When clipping image width to fit the screen, updatethe character count to match the clipped width to prevent buffer sizemismatches.Without the character count update, bit_putcs_aligned and bit_putcs_unalignedreceive mismatched parameters where the buffer is allocated for the clippedwidth but cnt reflects the original larger count, causing out-of-bounds writes.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_swThere is race in amdgpu_amdkfd_device_fini_sw and interrupt.if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated.kernel panic log:BUG: kernel NULL pointer dereference, address: 0000000000000098amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSPPGD d78c68067 P4D d78c68067kfd kfd: amdgpu: Allocated 3969056 bytes on gartPUD 1465b8067 PMD @Oops: @002 [#1] SMP NOPTIkfd kfd: amdgpu: Total number of KFD nodes to be created: 4CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE KRIP: 0010:_raw_spin_lock_irqsave+0x12/0x40Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc89 c6 e8 07 38 5dRSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000000180000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098ffff8883bb000000 RO8: ffff888100055020 ROO: ffff8881000550200000000000000000 R11: 0000000000000000 R12: 0900000000000002ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce00000000000000000 DR1: 0000000000000000 DR2: 00000000000000000000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400PKRU: 55555554Call Trace:kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]? amdgpu_fence_process+0xa4/0x150 [amdgpu]kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tEraceamdgpu_irq_dispatch+0x165/0x210 [amdgpu]amdgpu_ih_process+0x80/0x100 [amdgpu]amdgpu: Virtual CRAT table created for GPUamdgpu_irq_handler+0x1f/@x60 [amdgpu]__handle_irq_event_percpu+0x3d/0x170amdgpu: Topology: Add dGPU node [0x74a2:0x1002]handle_irq_event+0x5a/@xcOhandle_edge_irq+0x93/0x240kfd kfd: amdgpu: KFD node 1 partition @ size 49148Masm_call_irq_on_stack+0xf/@x20common_interrupt+0xb3/0x130asm_common_interrupt+0x1le/0x405.10.134-010.a1i5000.a18.x86_64 #1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: slimbus: fix bus_context pointer in regmap init callsCommit 4e65bda8273c ("ASoC: wcd934x: fix error handling inwcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.That commit breaks audio playback, for instance, on sdm845 ThundercommDragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19cThe __devm_regmap_init_slimbus() started to be used instead of__regmap_init_slimbus() after the commit mentioned above and turns outthe incorrect bus_context pointer (3rd argument) was used in__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equalto &slimbus->dev). Correct it. The wcd934x codec seems to be the only orthe first user of devm_regmap_init_slimbus() but we should fix it tillthe point where __devm_regmap_init_slimbus() was introduced thereforetwo "Fixes" tags.While at this, also correct the same argument in __regmap_init_slimbus().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Sync pending IRQ work before freeing ring bufferFix a race where irq_work can be queued in bpf_ringbuf_commit()but the ring buffer is freed before the work executes.In the syzbot reproducer, a BPF program attached to sched_switchtriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring bufferis freed before this work executes, the irq_work thread may accessesfreed memory.Calling `irq_work_sync(&rb->work)` ensures that all pending irq_workcomplete before freeing the buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix crash while sending Action Frames in standalone AP ModeCurrently, whenever there is a need to transmit an Action frame,the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR tofirmware. The P2P interfaces were available when wpa_supplicant is managingthe wlan interface.However, the P2P interfaces are not created/initialized when only hostapdis managing the wlan interface. And if hostapd receives an ANQP Query REQAction frame even from an un-associated STA, the brcmfmac driver triesto use an uninitialized P2P vif pointer for sending the IOVAR to firmware.This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)Fix this, by always using the vif corresponding to the wdev on which theAction frame Transmission request was initiated by the userspace. This way,even if P2P vif is not available, the IOVAR is sent to firmware on AP vifand the ANQP Query RESP Action frame is transmitted without crashing thedriver.Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()to brcmf_p2p_attach(). Because the former function would not get executedwhen only hostapd is managing wlan interface, and it is not safe to doreinit_completion() later in brcmf_p2p_tx_action_frame(), without any priorinit_completion().And in the brcmf_p2p_tx_action_frame() function, the condition check forP2P Presence response frame is not needed, since the wpa_supplicant isproperly sending the P2P Presense Response frame on the P2P-GO vif insteadof the P2P-Device vif.[Cc stable]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix crash in nfsd4_read_release()When tracing is enabled, the trace_nfsd_read_done trace pointcrashes during the pynfs read.testNoFh test.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_close_cached_fid()find_or_create_cached_dir() could grab a new reference after kref_put()had seen the refcount drop to zero but before cfid_list_lock is acquiredin smb2_close_cached_fid(), leading to use-after-free.Switch to kref_put_lock() so cfid_release() is called withcfid_list_lock held, closing that gap.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()which causes the code to proceed with NULL clock pointers. The currentlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for bothvalid pointers and NULL, leading to potential NULL pointer dereferencein clk_get_rate().Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:"The error code within @ptr if it is an error pointer; 0 otherwise."This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULLpointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to becalled when of_clk_get() returns NULL.Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for validpointers, preventing potential NULL pointer dereference in clk_get_rate().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: fix the deadlock of enetc_mdio_lockAfter applying the workaround for err050089, the LS1028A platformexperiences RCU stalls on RT kernel. This issue is caused by therecursive acquisition of the read lock enetc_mdio_lock. Here list someof the call stacks identified under the enetc_poll path that may lead toa deadlock:enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdioAfter enetc_poll acquires the read lock, a higher-priority writer attemptsto acquire the lock, causing preemption. The writer detects that aread lock is already held and is scheduled out. However, readers underenetc_poll cannot acquire the read lock again because a writer is alreadywaiting, leading to a thread hang.Currently, the deadlock is avoided by adjusting enetc_lock_mdio to preventrecursive lock acquisition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysfs: check visibility before changing group attribute ownershipSince commit 0c17270f9b92 ("net: sysfs: Implement is_visible forphys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() canhit WARN_ON() when trying to change owner of a file that isn't visible.See the trace below: WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30 [...] Call Trace: ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 ? sched_clock+0x10/0x30 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Fix this by checking is_visible() before trying to touch the attribute.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sysfb: Do not dereference NULL pointer in plane resetThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do notderef that pointer, but forward NULL to the other plane-reset helpers.Clears plane->state to NULL.v2:- fix typo in commit description (Javier)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure XFD state on signal deliverySean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Chao further identified [2] a reproducible scenario involving signaldelivery: a non-AMX task is preempted by an AMX-enabled task whichmodifies the XFD MSR.When the non-AMX task resumes and reloads XSTATE with init values,a warning is triggered due to a mismatch between fpstate::xfd and theCPU's current XFD state. fpu__clear_user_states() does not currentlyre-synchronize the XFD state after such preemption.Invoke xfd_update_state() which detects and corrects the mismatch ifthere is a dynamic feature.This also benefits the sigreturn path, as fpu__restore_sig() may callfpu__clear_user_states() when the sigframe is inaccessible.[ dhansen: minor changelog munging ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: enhance kfd process check in switch partitioncurrent switch partition only check if kfd_processes_table is empty.kfd_prcesses_table entry is deleted in kfd_process_notifier_release, butkfd_process tear down is in kfd_process_wq_release.consider two processes:Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node memberProcess B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw-> kfd_node tear down.Process A and B may trigger a race as shown in dmesg log.This patch is to resolve the race by adding an atomic kfd_process counterkfd_processes_count, it increment as create kfd process, decrement asfinish kfd_process_wq_release.v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pddsand bug fix. (Philip Yang)[3966658.307702] divide error: 0000 [#1] SMP NOPTI[3966658.350818] i10nm_edac[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu][3966658.362839] nfit[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu][3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00[3966658.380967] x86_pkg_temp_thermal[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[3966658.391536] PKRU: 55555554[3966658.391536] Call Trace:[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu][3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu][3966658.399754] intel_powerclamp[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu][3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu][3966658.410516] coretemp[3966658.434016] process_one_work+0x1ad/0x380[3966658.434021] worker_thread+0x49/0x310[3966658.438963] kvm_intel[3966658.446041] ? process_one_work+0x380/0x380[3966658.446045] kthread+0x118/0x140[3966658.446047] ? __kthread_bind_mask+0x60/0x60[3966658.446050] ret_from_fork+0x1f/0x30[3966658.446053] Modules linked in: kpatch_20765354(OEK)[3966658.455310] kvm[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)[3966658.473462] idxd_mdev[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: cadence: Check for the existence of cdns_pcie::ops before using itcdns_pcie::ops might not be populated by all the Cadence glue drivers. Thisis going to be true for the upcoming Sophgo platform which doesn't set theops.Hence, add a check to prevent NULL pointer dereference.[mani: reworded subject and description]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencingTheoretically it's an oopsable race, but I don't believe one can manageto hit it on real hardware; might become doable on a KVM, but it stillwon't be easy to attack.Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call ofput_unaligned_be64(), we can put that under ->d_lock and be done with that.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: use netdev_warn() instead of netdev_WARN()netdev_WARN() uses WARN/WARN_ON to print a backtrace along withfile and line information. In this case, udp_tunnel_nic_register()returning an error is just a failed operation, not a kernel bug.udp_tunnel_nic_register() can fail due to a memory allocationfailure (kzalloc() or udp_tunnel_nic_alloc()).This is a normal runtime error and not a kernel bug.Replace netdev_WARN() with netdev_warn() accordingly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixupRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.This can trigger kernel panics on ARM64 when xfrm or other subsystemsaccess the offset due to strict alignment checks.Initialize the MAC header to prevent such crashes.This can trigger kernel panics on ARM when running IPsec over theqmimux0 interface.Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add bpf_prog_run_data_pointers()syzbot found that cls_bpf_classify() is able to changetc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:Extend qdisc control block with tc control block"), which added a wronginteraction with db58ba459202 ("bpf: wire in data and data_end forcls_act_bpf").drop_reason was added later.Add bpf_prog_run_data_pointers() helper to save/restore the net_schedstorage colliding with BPF data_meta/data_end.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: remove two invalid BUG_ON()sThose can be triggered trivially by userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlx5: Fix default values in create CQCurrently, CQs without a completion function are assigned themlx5_add_cq_to_tasklet function by default. This is problematic sinceonly user CQs created through the mlx5_ib driver are intended to usethis function.Additionally, all CQs that will use doorbells instead of polling forcompletions must call mlx5_cq_arm. However, the default CQ creation flowleaves a valid value in the CQ's arm_db field, allowing FW to sendinterrupts to polling-only CQs in certain corner cases.These two factors would allow a polling-only kernel CQ to be triggeredby an EQ interrupt and call a completion function intended only for userCQs, causing a null pointer exception.Some areas in the driver have prevented this issue with one-off fixesbut did not address the root cause.This patch fixes the described issue by adding defaults to the create CQflow. It adds a default dummy completion function to protect againstnull pointer exceptions, and it sets an invalid command sequence numberby default in kernel CQs to prevent the FW from sending an interrupt tothe CQ until it is armed. User CQs are responsible for their owninitialization values.Callers of mlx5_core_create_cq are responsible for changing thecompletion function and arming the CQ per their needs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Fix proto fallback detection with BPFThe sockmap feature allows bpf syscall from userspace, or basedon bpf sockops, replacing the sk_prot of sockets during protocol stackprocessing with sockmap's custom read/write interfaces.'''tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot'''When the server has MPTCP enabled but the client sends a TCP SYNwithout MPTCP, subflow_syn_recv_sock() performs a fallback on thesubflow, replacing the subflow sk's sk_prot with the native sk_prot.'''subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override()'''Then, this subflow can be normally used by sockmap, which replaces thenative sk_prot with sockmap's custom sk_prot. The issue occurs when theuser executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().Here, it uses sk->sk_prot to compare with the native sk_prot, but thisis incorrect when sockmap is used, as we may incorrectly setsk->sk_socket->ops.This fix uses the more generic sk_family for the comparison instead.Additionally, this also prevents a WARNING from occurring:result from ./scripts/decode_stacktrace.sh:------------[ cut here ]------------WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \(net/mptcp/protocol.c:4005)Modules linked in:...PKRU: 55555554Call Trace:do_accept (net/socket.c:1989)__sys_accept4 (net/socket.c:2028 net/socket.c:2057)__x64_sys_accept (net/socket.c:2067)x64_sys_call (arch/x86/entry/syscall_64.c:41)do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)RIP: 0033:0x7f87ac92b83d---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Add call to put_pid()Add a call to put_pid() corresponding to get_task_pid().host1x_memory_context_alloc() does not take ownership of the PID so weneed to free it here to avoid leaking.[mperttunen@nvidia.com: reword commit message]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: restore write access before closing files opened by open_exec()bm_register_write() opens an executable file using open_exec(), whichinternally calls do_open_execat() and denies write access on the file toavoid modification while it is being executed.However, when an error occurs, bm_register_write() closes the file usingfilp_close() directly. This does not restore the write permission, whichmay cause subsequent write operations on the same file to fail.Fix this by calling exe_file_allow_write_access() before filp_close() torestore the write permission properly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDOn completion of i915_vma_pin_ww(), a synchronous variant ofdma_fence_work_commit() is called. When pinning a VMA to GGTT addressspace on a Cherry View family processor, or on a Broxton generation SoCwith VTD enabled, i.e., when stop_machine() is then called fromintel_ggtt_bind_vma(), that can potentially lead to lock inversion amongreservation_ww and cpu_hotplug locks.[86.861179] ======================================================[86.861193] WARNING: possible circular locking dependency detected[86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U[86.861226] ------------------------------------------------------[86.861238] i915_module_loa/1432 is trying to acquire lock:[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50[86.861290]but task is already holding lock:[86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915][86.862233]which lock already depends on the new lock.[86.862251]the existing dependency chain (in reverse order) is:[86.862265]-> #5 (reservation_ww_class_mutex){+.+.}-{3:3}:[86.862292] dma_resv_lockdep+0x19a/0x390[86.862315] do_one_initcall+0x60/0x3f0[86.862334] kernel_init_freeable+0x3cd/0x680[86.862353] kernel_init+0x1b/0x200[86.862369] ret_from_fork+0x47/0x70[86.862383] ret_from_fork_asm+0x1a/0x30[86.862399]-> #4 (reservation_ww_class_acquire){+.+.}-{0:0}:[86.862425] dma_resv_lockdep+0x178/0x390[86.862440] do_one_initcall+0x60/0x3f0[86.862454] kernel_init_freeable+0x3cd/0x680[86.862470] kernel_init+0x1b/0x200[86.862482] ret_from_fork+0x47/0x70[86.862495] ret_from_fork_asm+0x1a/0x30[86.862509]-> #3 (&mm->mmap_lock){++++}-{3:3}:[86.862531] down_read_killable+0x46/0x1e0[86.862546] lock_mm_and_find_vma+0xa2/0x280[86.862561] do_user_addr_fault+0x266/0x8e0[86.862578] exc_page_fault+0x8a/0x2f0[86.862593] asm_exc_page_fault+0x27/0x30[86.862607] filldir64+0xeb/0x180[86.862620] kernfs_fop_readdir+0x118/0x480[86.862635] iterate_dir+0xcf/0x2b0[86.862648] __x64_sys_getdents64+0x84/0x140[86.862661] x64_sys_call+0x1058/0x2660[86.862675] do_syscall_64+0x91/0xe90[86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e[86.862703]-> #2 (&root->kernfs_rwsem){++++}-{3:3}:[86.862725] down_write+0x3e/0xf0[86.862738] kernfs_add_one+0x30/0x3c0[86.862751] kernfs_create_dir_ns+0x53/0xb0[86.862765] internal_create_group+0x134/0x4c0[86.862779] sysfs_create_group+0x13/0x20[86.862792] topology_add_dev+0x1d/0x30[86.862806] cpuhp_invoke_callback+0x4b5/0x850[86.862822] cpuhp_issue_call+0xbf/0x1f0[86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320[86.862852] __cpuhp_setup_state+0xb0/0x220[86.862866] topology_sysfs_init+0x30/0x50[86.862879] do_one_initcall+0x60/0x3f0[86.862893] kernel_init_freeable+0x3cd/0x680[86.862908] kernel_init+0x1b/0x200[86.862921] ret_from_fork+0x47/0x70[86.862934] ret_from_fork_asm+0x1a/0x30[86.862947]-> #1 (cpuhp_state_mutex){+.+.}-{3:3}:[86.862969] __mutex_lock+0xaa/0xed0[86.862982] mutex_lock_nested+0x1b/0x30[86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320[86.863012] __cpuhp_setup_state+0xb0/0x220[86.863026] page_alloc_init_cpuhp+0x2d/0x60[86.863041] mm_core_init+0x22/0x2d0[86.863054] start_kernel+0x576/0xbd0[86.863068] x86_64_start_reservations+0x18/0x30[86.863084] x86_64_start_kernel+0xbf/0x110[86.863098] common_startup_64+0x13e/0x141[86.863114]-> #0 (cpu_hotplug_lock){++++}-{0:0}:[86.863135] __lock_acquire+0x16---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: hdm_probe: Fix calling put_device() before device initializationThe early error path in hdm_probe() can jump to err_free_mdev before&mdev->dev has been initialized with device_initialize(). Callingput_device(&mdev->dev) there triggers a device core WARN and ends upinvoking kref_put(&kobj->kref, kobject_release) on an uninitializedkobject.In this path the private struct was only kmalloc'ed and the intendedrelease is effectively kfree(mdev) anyway, so free it directly insteadof calling put_device() on an uninitialized device.This removes the WARNING and fixes the pre-initialization error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: check device's attached status in compat ioctlsSyzbot identified an issue [1] that crashes kernel, seemingly due tounexistent callback dev->get_valid_routes(). By all means, this shouldnot occur as said callback must always be set toget_zero_valid_routes() in __comedi_device_postconfig().As the crash seems to appear exclusively in i386 kernels, at least,judging from [1] reports, the blame lies with compat versionsof standard IOCTL handlers. Several of them are modified anddo not use comedi_unlocked_ioctl(). While functionality of theseioctls essentially copy their original versions, they do nothave required sanity check for device's attached status. This,in turn, leads to a possibility of calling select IOCTLs on adevice that has not been properly setup, even via COMEDI_DEVCONFIG.Doing so on unconfigured devices means that several crucial stepsare missed, for instance, specifying dev->get_valid_routes()callback.Fix this somewhat crudely by ensuring device's attached status beforeperforming any ioctls, improving logic consistency between modernand compat functions.[1] Syzbot report:BUG: kernel NULL pointer dereference, address: 0000000000000000...CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0Call Trace: get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [inline] __se_compat_sys_ioctl fs/ioctl.c:638 [inline] __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: multiq3: sanitize config options in multiq3_attach()Syzbot identified an issue [1] in multiq3_attach() that induces atask timeout due to open() or COMEDI_DEVCONFIG ioctl operations,specifically, in the case of multiq3 driver.This problem arose when syzkaller managed to craft weird configurationoptions used to specify the number of channels in encoder subdevice.If a particularly great number is passed to s->n_chan inmultiq3_attach() via it->options[2], then multiple calls tomultiq3_encoder_reset() at the end of driver-specific attach() methodwill be running for minutes, thus blocking tasks and affected devicesas well.While this issue is most likely not too dangerous for real-lifedevices, it still makes sense to sanitize configuration inputs. Enablea sensible limit on the number of encoder chips (4 chips max, eachwith 2 channels) to stop this behaviour from manifesting.[1] Syzbot crash:INFO: task syz.2.19:6067 blocked for more than 143 seconds....Call Trace: context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call pathsThis patch addresses a race condition caused by unsynchronizedexecution of multiple call paths invoking `dwc3_remove_requests()`,leading to premature freeing of USB requests and subsequent crashes.Three distinct execution paths interact with `dwc3_remove_requests()`:Path 1:Triggered via `dwc3_gadget_reset_interrupt()` during USB resethandling. The call stack includes:- `dwc3_ep0_reset_state()`- `dwc3_ep0_stall_and_restart()`- `dwc3_ep0_out_start()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 2:Also initiated from `dwc3_gadget_reset_interrupt()`, but through`dwc3_stop_active_transfers()`. The call stack includes:- `dwc3_stop_active_transfers()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 3:Occurs independently during `adb root` execution, which triggersUSB function unbind and bind operations. The sequence includes:- `gserial_disconnect()`- `usb_ep_disable()`- `dwc3_gadget_ep_disable()`- `dwc3_remove_requests()` with `-ESHUTDOWN` statusPath 3 operates asynchronously and lacks synchronization with Paths1 and 2. When Path 3 completes, it disables endpoints and frees 'out'requests. If Paths 1 or 2 are still processing these requests,accessing freed memory leads to a crash due to use-after-free conditions.To fix this added check for request completion and skip processingif already completed and added the request status for ep0 while queue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix memory leak in eem_unwrapThe existing code did not handle the failure case of usb_ep_queue in thecommand path, potentially leading to memory leaks.Improve error handling to free all allocated resources on usb_ep_queuefailure. This patch continues to use goto logic for error handling, as theexisting error handling is complex and not easily adaptable to auto-cleanuphelpers.kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: fix double free on late probe failureThe MOST subsystem has a non-standard registration function which freesthe interface on registration failures and on deregistration.This unsurprisingly leads to bugs in the MOST drivers, and a couple ofrecent changes turned a reference underflow and use-after-free in theUSB driver into several double free and a use-after-free on late probefailures.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix crash in process_v2_sparse_read() for encrypted directoriesThe crash in process_v2_sparse_read() for fscrypt-encrypted directorieshas been reported. Issue takes place for Ceph msgr2 protocol in securemode. It can be reproduced by the steps:sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure(1) mkdir /mnt/cephfs/fscrypt-test-3(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3(4) fscrypt lock /mnt/cephfs/fscrypt-test-3(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar(7) Issue has been triggered[ 408.072247] ------------[ cut here ]------------[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_commonintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discoverypmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypasspolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouseserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfgpata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.17.0-5.fc42 04/01/2014[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f88e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)knlGS:0000000000000000[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0[ 408.072336] PKRU: 55555554[ 408.072337] Call Trace:[ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10[ 408.072347] ? _raw_spin_unlock+0xe/0x40[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830[ 408.072353] ? __kasan_check_write+0x14/0x30[ 408.072357] ? mutex_lock+0x84/0xe0[ 408.072359] ? __pfx_mutex_lock+0x10/0x10[ 408.072361] ceph_con_workfn+0x27e/0x10e0[ 408.072364] ? metric_delayed_work+0x311/0x2c50[ 408.072367] process_one_work+0x611/0xe20[ 408.072371] ? __kasan_check_write+0x14/0x30[ 408.072373] worker_thread+0x7e3/0x1580[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 408.072378] ? __pfx_worker_thread+0x10/0x10[ 408.072381] kthread+0x381/0x7a0[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10[ 408.072385] ? __pfx_kthread+0x10/0x10[ 408.072387] ? __kasan_check_write+0x14/0x30[ 408.072389] ? recalc_sigpending+0x160/0x220[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50[ 408.072394] ? calculate_sigpending+0x78/0xb0[ 408.072395] ? __pfx_kthread+0x10/0x10[ 408.072397] ret_from_fork+0x2b6/0x380[ 408.072400] ? __pfx_kthread+0x10/0x10[ 408.072402] ret_from_fork_asm+0x1a/0x30[ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]---[ 408.072418] Oops: general protection fault, probably for non-canonicaladdress 0xdffffc00000000---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: fix fragment overflow handling in RX pathThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)fragments when handling large multi-descriptor packets. This causes anout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.The issue occurs because the driver doesn't check the total number offragments before calling skb_add_rx_frag(). When a packet requires morethan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,then all fragments are accounted for. And reusing the existing check toprevent the overflow earlier in the code path.This crash occurred in production with an Aquantia AQC113 10G NIC.Stack trace from production environment:```RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 4889 fa 83RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:fffffffe0a0c8000RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:0000000000037a40RBP: 0000000000000024 R08: 0000000000000000 R09:0000000000000021R10: 0000000000000848 R11: 0000000000000000 R12:ffffa9bec02a8e24R13: ffff925ad8615570 R14: 0000000000000000 R15:ffff925b22e80a00FS: 0000000000000000(0000)GS:ffff925e47880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:0000000000f72ef0PKRU: 55555554Call Trace:aq_ring_rx_clean+0x175/0xe60 [atlantic]? aq_ring_rx_clean+0x14d/0xe60 [atlantic]? aq_ring_tx_clean+0xdf/0x190 [atlantic]? kmem_cache_free+0x348/0x450? aq_vec_poll+0x81/0x1d0 [atlantic]? __napi_poll+0x28/0x1c0? net_rx_action+0x337/0x420```Changes in v4:- Add Fixes: tag to satisfy patch validation requirements.Changes in v3:- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: intel: punit_ipc: fix memory corruptionThis passes the address of the pointer "&punit_ipcdev" when the intentwas to pass the pointer itself "punit_ipcdev" (without the ampersand).This means that the: complete(&ipcdev->cmd_complete);in intel_punit_ioc() will write to a wrong memory address corrupting it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: leaf: Fix potential infinite loop in command parsersThe `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`functions contain logic to zero-length commands. These commands are usedto align data to the USB endpoint's wMaxPacketSize boundary.The driver attempts to skip these placeholders by aligning the bufferposition `pos` to the next packet boundary using `round_up()` function.However, if zero-length command is found exactly on a packet boundary(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`function will return the unchanged value of `pos`. This prevents `pos`to be increased, causing an infinite loop in the parsing logic.This patch fixes this in the function by using `pos + 1` instead.This ensures that even if `pos` is on a boundary, the calculation isbased on `pos + 1`, forcing `round_up()` to always return the nextaligned boundary.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Prevents free active keventThe root cause of this issue are:1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);put the kevent work in global workqueue. However, the kevent has not yetbeen scheduled when the usbnet device is unregistered. Therefore, executingfree_netdev() results in the "free active object (kevent)" error reportedhere.2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),if the usbnet device is up, ndo_stop() is executed to cancel the kevent.However, because the device is not up, ndo_stop() is not executed.The solution to this problem is to cancel the kevent before executingfree_netdev().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: bmc150: Fix irq assumption regressionThe code in bmc150-accel-core.c unconditionally callsbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,such as on the runtime PM resume path giving a kernelsplat like this if the device has no interrupts:Unable to handle kernel NULL pointer dereference at virtual address 00000001 when readPC is at bmc150_accel_set_interrupt+0x98/0x194LR is at __pm_runtime_resume+0x5c/0x64(...)Call trace:bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc__iio_update_buffers from enable_store+0x84/0xc8enable_store from kernfs_fop_write_iter+0x154/0x1b4This bug seems to have been in the driver since the beginning,but it only manifests recently, I do not know why.Store the IRQ number in the state struct, as this is a commonpattern in other drivers, then use this to determine if we haveIRQ support or not.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()The acpi_get_first_physical_node() function can return NULL, in whichcase the get_device() function also returns NULL, but this value isthen dereferenced without checking,so add a check to prevent a crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: dice: fix buffer overflow in detect_stream_formats()The function detect_stream_formats() reads the stream_count value directlyfrom a FireWire device without validating it. This can lead toout-of-bounds writes when a malicious device provides a stream_count valuegreater than MAX_STREAMS.Fix by applying the same validation to both TX and RX stream counts indetect_stream_formats().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexregulator_supply_alias_list was accessed without any locking inregulator_supply_alias(), regulator_register_supply_alias(), andregulator_unregister_supply_alias(). Concurrent registration,unregistration and lookups can race, leading to:1 use-after-free if an alias entry is removed while being read,2 duplicate entries when two threads register the same alias,3 inconsistent alias mappings observed by consumers.Protect all traversals, insertions and deletions onregulator_supply_alias_list with the existing regulator_list_mutex.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()The rtl8187_rx_cb() calculates the rx descriptor header addressby subtracting its size from the skb tail pointer.However, it does not validate if the received packet(skb->len from urb->actual_length) is large enough to contain thisheader.If a truncated packet is received, this will lead to a bufferunderflow, reading memory before the start of the skb data area,and causing a kernel panic.Add length checks for both rtl8187 and rtl8187b descriptor headersbefore attempting to access them, dropping the packet cleanly if thecheck fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check skb->transport_header is set in bpf_skb_check_mtuThe bpf_skb_check_mtu helper needs to use skb->transport_header whenthe BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)The transport_header is not always set. There is a WARN_ON_ONCEreport when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +bpf_prog_test_run is used:WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skbFor a normal ingress skb (not test_run), skb_reset_transport_headeris performed but there is plan to avoid setting it as described incommit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").This patch fixes the bpf helper by checkingskb_transport_header_was_set(). The check is done just beforeskb->transport_header is used, to avoid breaking the existing bpf prog.The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check in __bpf_get_stackid()Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix peer HE MCS assignmentIn ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent tofirmware as receive MCS while peer's receive MCS sent as transmit MCS,which goes against firmwire's definition.While connecting to a misbehaved AP that advertises 0xffff (meaning notsupported) for 160 MHz transmit MCS map, firmware crashes due to 0xffffis assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffffSwap the assignment to fix this issue.As the HE rate control mask is meant to limit our own transmit MCS, itneeds to go via he_mcs->rx_mcs_set field. With the aforementioned swappingdone, change is needed as well to apply it to the peer's receive MCS.Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_idUse check_add_overflow() to guard against potential integer overflowswhen adding the binary blob lengths and the size of an asymmetric_key_idstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents apossible buffer overflow when copying data from potentially maliciousX.509 certificate fields that can be arbitrarily large, such as ASN.1INTEGER serial numbers, issuer names, etc.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not let BPF test infra emit invalid GSO types to stackYinhao et al. reported that their fuzzer tool was able to trigger askb_warn_bad_offload() from netif_skb_features() -> gso_features_check().When a BPF program - triggered via BPF test infra - pushes the packetto the loopback device via bpf_clone_redirect() then mentioned offloadwarning can be seen. GSO-related features are then rightfully disabled.We get into this situation due to convert___skb_to_skb() settinggso_segs and gso_size but not gso_type. Technically, it makes sensethat this warning triggers since the GSO properties are malformed dueto the gso_type. Potentially, the gso_type could be marked non-trustworthythrough setting it at least to SKB_GSO_DODGY without any other specificassumptions, but that also feels wrong given we should not go furtherinto the GSO engine in the first place.The checks were added in 121d57af308d ("gso: validate gso_type in GSOhandlers") because there were malicious (syzbot) senders that combinea protocol with a non-matching gso_type. If we would want to drop suchpackets, gso_features_check() currently only returns feature flags vianetif_skb_features(), so one location for potentially dropping such skbscould be validate_xmit_unreadable_skb(), but then otoh it would bean additional check in the fast-path for a very corner case. Givenbpf_clone_redirect() is the only place where BPF test infra could emitsuch packets, lets reject them right there.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: Handle error code returned by ima_filter_rule_match()In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due tothe rule being NULL, the function incorrectly skips the 'if (!rc)' checkand sets 'result = true'. The LSM rule is considered a match, causingextra files to be measured by IMA.This issue can be reproduced in the following scenario:After unloading the SELinux policy module via 'semodule -d', if an IMAmeasurement is triggered before ima_lsm_rules is updated,in ima_match_rules(), the first call to ima_filter_rule_match() returns-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. Inima_lsm_copy_rule(), since the SELinux module has been removed, the rulebecomes NULL, and the second call to ima_filter_rule_match() returns-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that errorcodes like -ENOENT do not bypass the check and accidentally result in asuccessful match.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vgem-fence: Fix potential deadlock on releaseA timer that expires a vgem fence automatically in 10 seconds is nowreleased with timer_delete_sync() from fence->ops.release() called on lastdma_fence_put(). In some scenarios, it can run in IRQ context, which isnot safe unless TIMER_IRQSAFE is used. One potentially risky scenario wasdemonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, whileworking on new IGT subtests syncobj_timeline@stress-* as user spacereplacements of some problematic test cases of a dma-fence-chain selftest[1].[117.004338] ================================[117.004340] WARNING: inconsistent lock state[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U[117.004346] --------------------------------[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190[117.004361] {HARDIRQ-ON-W} state was registered at:[117.004363] lock_acquire+0xc4/0x2e0[117.004366] call_timer_fn+0x80/0x2a0[117.004368] __run_timers+0x231/0x310[117.004370] run_timer_softirq+0x76/0xe0[117.004372] handle_softirqs+0xd4/0x4d0[117.004375] __irq_exit_rcu+0x13f/0x160[117.004377] irq_exit_rcu+0xe/0x20[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20[117.004385] cpuidle_enter_state+0x12b/0x8a0[117.004388] cpuidle_enter+0x2e/0x50[117.004393] call_cpuidle+0x22/0x60[117.004395] do_idle+0x1fd/0x260[117.004398] cpu_startup_entry+0x29/0x30[117.004401] start_secondary+0x12d/0x160[117.004404] common_startup_64+0x13e/0x141[117.004407] irq event stamp: 2282669[117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80[117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0[117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18[117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160[117.004426]other info that might help us debug this:[117.004429] Possible unsafe locking scenario:[117.004432] CPU0[117.004433] ----[117.004434] lock((&fence->timer));[117.004436] [117.004438] lock((&fence->timer));[117.004440] *** DEADLOCK ***[117.004443] 1 lock held by swapper/0/0:[117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0[117.004450]stack backtrace:[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023[117.004456] Call Trace:[117.004456] [117.004457] dump_stack_lvl+0x91/0xf0[117.004460] dump_stack+0x10/0x20[117.004461] print_usage_bug.part.0+0x260/0x360[117.004463] mark_lock+0x76e/0x9c0[117.004465] ? register_lock_class+0x48/0x4a0[117.004467] __lock_acquire+0xbc3/0x2860[117.004469] lock_acquire+0xc4/0x2e0[117.004470] ? __timer_delete_sync+0x4b/0x190[117.004472] ? __timer_delete_sync+0x4b/0x190[117.004473] __timer_delete_sync+0x68/0x190[117.004474] ? __timer_delete_sync+0x4b/0x190[117.004475] timer_delete_sync+0x10/0x20[117.004476] vgem_fence_release+0x19/0x30 [vgem][117.004478] dma_fence_release+0xc1/0x3b0[117.004480] ? dma_fence_release+0xa1/0x3b0[117.004481] dma_fence_chain_release+0xe7/0x130[117.004483] dma_fence_release+0xc1/0x3b0[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80[117.004485] dma_fence_chain_irq_work+0x59/0x80[117.004487] irq_work_single+0x75/0xa0[117.004490] irq_work_r---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMAallocations in a loop. When an allocation fails, the previouslysuccessful allocations are not freed on exit.Fix that by jumping to err_free_rings label on error, which callsrtl8180_free_rx_ring() to free the allocations. Remove the free ofrx_ring in rtl8180_init_rx_ring() error path, and set the freedpriv->rx_buf entry to null, to avoid double free.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If thesubsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the functionreturns an error without freeing sskb, leading to a memory leak.Fix this by calling dev_kfree_skb() on sskb in the error handling pathto ensure it is properly released.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix return value of f2fs_recover_fsync_data()With below scripts, it will trigger panic in f2fs:mkfs.f2fs -f /dev/vddmount /dev/vdd /mnt/f2fstouch /mnt/f2fs/foosyncecho 111 >> /mnt/f2fs/foof2fs_io fsync /mnt/f2fs/foof2fs_io shutdown 2 /mnt/f2fsumount /mnt/f2fsmount -o ro,norecovery /dev/vdd /mnt/f2fsormount -o ro,disable_roll_forward /dev/vdd /mnt/f2fsF2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361fF2FS-fs (vdd): Stopped filesystem due to reason: 0F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1Filesystem f2fs get_tree() didn't set fc->root, returned 1------------[ cut here ]------------kernel BUG at fs/super.c:1761!Oops: invalid opcode: 0000 [#1] SMP PTICPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vfs_get_tree.cold+0x18/0x1aCall Trace: fc_mount+0x13/0xa0 path_mount+0x34e/0xc50 __x64_sys_mount+0x121/0x150 do_syscall_64+0x84/0x800 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fa6cc126cfeThe root cause is we missed to handle error number returned fromf2fs_recover_fsync_data() when mounting image w/ ro,norecovery orro,disable_roll_forward mount option, result in returning a positiveerror number to vfs_get_tree(), fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix kernel BUG in ocfs2_find_victim_chainsyzbot reported a kernel BUG in ocfs2_find_victim_chain() because the`cl_next_free_rec` field of the allocation chain list (next free slot inthe chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)condition in ocfs2_find_victim_chain() and panicking the kernel.To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),just before calling ocfs2_find_victim_chain(), the code block in it beingexecuted when either of the following conditions is true:1. `cl_next_free_rec` is equal to 0, indicating that there are no freechains in the allocation chain list2. `cl_next_free_rec` is greater than `cl_count` (the total number ofchains in the allocation chain list)Either of them being true is indicative of the fact that there are nochains left for usage.This is addressed using ocfs2_error(), which printsthe error log for debugging purposes, rather than panicking the kernel.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-mixer: us16x08: validate meter packet indicesget_meter_levels_from_urb() parses the 64-byte meter packets sent bythe device and fills the per-channel arrays meter_level[],comp_level[] and master_level[] in struct snd_us16x08_meter_store.Currently the function derives the channel index directly from themeter packet (MUB2(meter_urb, s) - 1) and uses it to index thosearrays without validating the range. If the packet contains anegative or out-of-range channel number, the driver may write pastthe end of these arrays.Introduce a local channel variable and validate it before updating thearrays. We reject negative indices, limit meter_level[] andcomp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]updates with ARRAY_SIZE(master_level).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix memory leak in nr_sendmsg()syzbot reported a memory leak [1].When function sock_alloc_send_skb() return NULL in nr_output(), theoriginal skb is not freed, which was allocated in nr_sendmsg(). Fix thisby freeing it before return.[1]BUG: memory leakunreferenced object 0xffff888129f35500 (size 240): comm "syz.0.17", pid 6119, jiffies 4294944652 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(.... backtrace (crc 1456a3e4): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4983 [inline] slab_alloc_node mm/slub.c:5288 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671 sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965 sock_alloc_send_skb include/net/sock.h:1859 [inline] nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x293/0x2a0 net/socket.c:1195 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0x143/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating zero-sized extent in extent cacheAs syzbot reported:F2FS-fs (loop0): __update_extent_tree_range: extent len is zero, type: 0, extent [0, 0, 0], age [0, 0]------------[ cut here ]------------kernel BUG at fs/f2fs/extent_cache.c:678!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678Call Trace: f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085 f2fs_do_zero_range fs/f2fs/file.c:1657 [inline] f2fs_zero_range+0x10c1/0x1580 fs/f2fs/file.c:1737 f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030 vfs_fallocate+0x669/0x7e0 fs/open.c:342 ioctl_preallocate fs/ioctl.c:289 [inline] file_ioctl+0x611/0x780 fs/ioctl.c:-1 do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576 __do_sys_ioctl fs/ioctl.c:595 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f07bc58eec9In error path of f2fs_zero_range(), it may add a zero-sized extentinto extent cache, it should be avoided.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: initialize local pointers upon transfer of memory ownershipvidtv_channel_si_init() creates a temporary list (program, service, event)and ownership of the memory itself is transferred to the PAT/SDT/EITtables through vidtv_psi_pat_program_assign(),vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().The problem here is that the local pointer where the memory ownershiptransfer was completed is not initialized to NULL. This causes thevidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, andin the flow that jumps to free_eit, the memory that was freed byvidtv_psi_*_table_destroy() can be accessed again byvidtv_psi_*_event_destroy() due to the uninitialized local pointer, so itis freed once again.Therefore, to prevent use-after-free and double-free vulnerability,local pointers must be initialized to NULL when transferring memoryownership.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix filename leak in __io_openat_prep() __io_openat_prep() allocates a struct filename using getname(). However,for the condition of the file being installed in the fixed file table aswell as having O_CLOEXEC flag set, the function returns early. At thatpoint, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,the memory for the newly allocated struct filename is not cleaned up,causing a memory leak.Fix this by setting the REQ_F_NEED_CLEANUP for the request just after thesuccessful getname() call, so that when the request is torn down, thefilename will be cleaned up, along with other resources needing cleanup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Remove drr class from the active list if it changes to strictWhenever a user issues an ets qdisc change command, transforming adrr class into a strict one, the ets code isn't checking whether thatclass was in the active list and removing it. This means that, if auser changes a strict class (which was in the active list) back to a drrone, that class will be added twice to the active list [1].Doing so with the following commands:tc qdisc add dev lo root handle 1: ets bands 2 strict 1tc qdisc add dev lo parent 1:2 handle 20: \ tbf rate 8bit burst 100b latency 1stc filter add dev lo parent 1: basic classid 1:2ping -c1 -W0.01 -s 56 127.0.0.1tc qdisc change dev lo root handle 1: ets bands 2 strict 2tc qdisc change dev lo root handle 1: ets bands 2 strict 1ping -c1 -W0.01 -s 56 127.0.0.1Will trigger the following splat with list debug turned on:[ 59.279014][ T365] ------------[ cut here ]------------[ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.[ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220[ 59.280860][ T365] Modules linked in:[ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)[ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220[ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44...[ 59.288812][ T365] Call Trace:[ 59.289056][ T365] [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80[ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0[ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10[ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240[ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10[ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.292313][ T365] ? trace_contention_end+0xc8/0x110[ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0Fix this by always checking and removing an ets class from the active listwhen changing it to strict.[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()rlen value is a user-controlled value, but dtv5100_i2c_msg() does notcheck the size of the rlen value. Therefore, if it is set to a valuelarger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.Therefore, we need to add proper range checking to prevent this vuln.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Always remove class from active list before deleting in ets_qdisc_changezdi-disclosures@trendmicro.com says:The vulnerability is a race condition between `ets_qdisc_dequeue` and`ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.Attacker requires the capability to create new user and network namespacein order to trigger the bug.See my additional commentary at the end of the analysis.Analysis:static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack){... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc); } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0;}Comment:This happens because some of the classes have their qdiscs assigned toNULL, but remain in the active list. This commit fixes this issue by alwaysremoving the class from the active list before deleting and freeing itsassociated qdiscReproducer Steps(trimmed version of what was sent by zdi-disclosures@trendmicro.com)```DEV="${DEV:-lo}"ROOT_HANDLE="${ROOT_HANDLE:-1:}"BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2PING_BYTES="${PING_BYTES:-48}"PING_COUNT="${PING_COUNT:-200000}"PING_DST="${PING_DST:-127.0.0.1}"SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null}trap cleanup EXITip link set "$DEV" uptc qdisc del dev "$DEV" root 2>/dev/null || truetc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2tc -s qdisc ls dev $DEVping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 &tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc -s qdisc ls dev $DEVtc qdisc del dev "$DEV" parent ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: invalidate dentry cache on failed whiteout creationF2FS can mount filesystems with corrupted directory depth values thatget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUToperations are performed on such directories, f2fs_rename performsdirectory modifications (updating target entry and deleting sourceentry) before attempting to add the whiteout entry via f2fs_add_link.If f2fs_add_link fails due to the corrupted directory structure, thefunction returns an error to VFS, but the partial directorymodifications have already been committed to disk. VFS assumes theentire rename operation failed and does not update the dentry cache,leaving stale mappings.In the error path, VFS does not call d_move() to update the dentrycache. This results in new_dentry still pointing to the old inode(new_inode) which has already had its i_nlink decremented to zero.The stale cache causes subsequent operations to incorrectly referencethe freed inode.This causes subsequent operations to use cached dentry information thatno longer matches the on-disk state. When a second rename targets thesame entry, VFS attempts to decrement i_nlink on the stale inode, whichmay already have i_nlink=0, triggering a WARNING in drop_nlink().Example sequence:1. First rename (RENAME_WHITEOUT): file2 -> file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 -> inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)2. Second rename: file3 -> file1 - VFS uses stale cache: file1 -> inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()Fix this by explicitly invalidating old_dentry and new_dentry whenf2fs_add_link fails during whiteout creation. This forces VFS torefresh from disk on subsequent operations, ensuring cache consistencyeven when the rename partially succeeds.Reproducer:1. Mount F2FS image with corrupted i_current_depth2. renameat2(file2, file1, RENAME_WHITEOUT)3. renameat2(file3, file1, 0)4. System triggers WARNING in drop_nlink()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Cap the number of PCR bankstpm2_get_pcr_allocation() does not cap any upper limit for the number ofbanks. Cap the limit to eight banks so that out of bounds values comingfrom external I/O cause on only limited harm.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s/slb: Fix SLB multihit issue during SLB preloadOn systems using the hash MMU, there is a software SLB preload cache thatmirrors the entries loaded into the hardware SLB buffer. This preloadcache is subject to periodic eviction - typically after every 256 contextswitches - to remove old entry.To optimize performance, the kernel skips switch_mmu_context() inswitch_mm_irqs_off() when the prev and next mm_struct are the same.However, on hash MMU systems, this can lead to inconsistencies betweenthe hardware SLB and the software preload cache.If an SLB entry for a process is evicted from the software cache on oneCPU, and the same process later runs on another CPU without executingswitch_mmu_context(), the hardware SLB may retain stale entries. If thekernel then attempts to reload that entry, it can trigger an SLBmulti-hit error.The following timeline shows how stale SLB entries are created and cancause a multi-hit error when a process moves between CPUs without aMMU context switch.CPU 0 CPU 1----- -----Process Pexec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */context_switchsched_migrate_task migrates process P to cpu-1Process swapper/0 context switch (to process P)(uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb becomes 0 here * and we evict an entry from * the preload cache with * preload_age(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switch_slb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preload_cache * (after eviction). */ load_elf_binary continues... setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task migrates process P to cpu-0context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * Since both prev and next mm struct are same we don't call * switch_mmu_context(). This will cause the HW SLB and SW preload * cache to go out of sync in preload_new_slb_context. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preload_new_slb_context(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */load_elf_binary cont---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_writeA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()due to lock ordering inversion between device_lock and rfkill_global_mutex.The problematic lock order is:Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lockThread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutexThis creates a classic ABBA deadlock scenario.Fix this by moving rfkill_unregister() and rfkill_destroy() outside thedevice_lock critical section. Store the rfkill pointer in a local variablebefore releasing the lock, then call rfkill_unregister() after releasingdevice_lock.This change is safe because rfkill_fop_write() holds rfkill_global_mutexwhile calling the rfkill callbacks, and rfkill_unregister() also acquiresrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() willwait for any ongoing callback to complete before proceeding, anddevice_del() is only called after rfkill_unregister() returns, preventingany use-after-free.The similar lock ordering in nfc_register_device() (device_lock ->rfkill_global_mutex via rfkill_register) is safe because duringregistration the device is not yet in rfkill_list, so no concurrentrfkill operations can occur on this device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: revert use of devm_kzalloc in btusbThis reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc inbtusb.c file").In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. Thisties the lifetime of all the btusb data to the binding of a driver toone interface, INTF. In a driver that binds to other interfaces, ISOCand DIAG, this is an accident waiting to happen.The issue is revealed in btusb_disconnect(), where callingusb_driver_release_interface(&btusb_driver, data->intf) will have devmfree the data that is also being used by the other interfaces of thedriver that may not be released yet.To fix this, revert the use of devm and go back to freeing memoryexplicitly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Avoid NULL pointer deref for evicted BOsIt is possible for a BO to exist that is not currently associated with aresource, e.g. because it has been evicted.When devcoredump tries to read the contents of all BOs for dumping, we needto expect this as well -- in this case, ENODATA is recorded instead of thebuffer contents.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix the crash issue for zero copy XDP_TX actionThere is a crash issue when running zero copy XDP_TX action, the crashlog is shown below.[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000[ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP[ 216.301694] Call trace:[ 216.304130] dcache_clean_poc+0x20/0x38 (P)[ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0[ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400[ 216.317701] __stmmac_xdp_run_prog+0x164/0x368[ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00[ 216.326576] __napi_poll+0x40/0x218[ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interruptFor XDP_TX action, the xdp_buff is converted to xdp_frame byxdp_convert_buff_to_frame(). The memory type of the resulting xdp_framedepends on the memory type of the xdp_buff. For page pool based xdp_buffit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copyXSK pool based xdp_buff it produces xdp_frame with memory typeMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check thememory type and always uses the page pool type, this leads to invalidmappings and causes the crash. Therefore, check the xdp_buff memory typein stmmac_xdp_xmit_back() to fix this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: use global inline_xattr_slab instead of per-sb slab cacheAs Hong Yun reported in mailing list:loop7: detected capacity change from 0 to 131072------------[ cut here ]------------kmem_cache of name 'f2fs_xattr_entry-7:7' already existsWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307Call Trace: __kmem_cache_create include/linux/slab.h:353 [inline] f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline] f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692 vfs_get_tree+0x43/0x140 fs/super.c:1815 do_new_mount+0x201/0x550 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe bug can be reproduced w/ below scripts:- mount /dev/vdb /mnt1- mount /dev/vdc /mnt2- umount /mnt1- mounnt /dev/vdb /mnt1The reason is if we created two slab caches, named f2fs_xattr_entry-7:3and f2fs_xattr_entry-7:7, and they have the same slab size. Actually,slab system will only create one slab cache core structure which hasslab name of "f2fs_xattr_entry-7:3", and two slab caches share the samestructure and cache address.So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it willdecrease reference count of slab cache, rather than release slab cacheentirely, since there is one more user has referenced the cache.Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again,slab system will find that there is existed cache which has the same nameand trigger the warning.Let's changes to use global inline_xattr_slab instead of per-sb slab cachefor fixing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (w83791d) Convert macros to functions to avoid TOCTOUThe macro FAN_FROM_REG evaluates its arguments multiple times. When usedin lockless contexts involving shared driver data, this leads toTime-of-Check to Time-of-Use (TOCTOU) race conditions, potentiallycausing divide-by-zero errors.Convert the macro to a static function. This guarantees that argumentsare evaluated only once (pass-by-value), preventing the raceconditions.Additionally, in store_fan_div, move the calculation of the minimumlimit inside the update lock. This ensures that the read-modify-writesequence operates on consistent data.Adhere to the principle of minimal changes by only converting macrosthat evaluate arguments multiple times and are used in locklesscontexts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Avoid walking the Namespace if start_node is NULLAlthough commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespaceif it is not there") fixed the situation when both start_node andacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashedon Honor Magicbook 14 Pro [1].That happens due to the access to the member of parent_node inacpi_ns_get_next_node(). The NULL pointer dereference will alwayshappen, no matter whether or not the start_node is equal toACPI_ROOT_OBJECT, so move the check of start_node being NULLout of the if block.Unfortunately, all the attempts to contact Honor have failed, theyrefused to provide any technical support for Linux.The bad DSDT table's dump could be found on GitHub [2].DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025[ rjw: Subject adjustment, changelog edits ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbufferInitialize the eb.vma array with values of 0 when the eb structure isfirst set up. In particular, this sets the eb->vma[i].vma pointers toNULL, simplifying cleanup and getting rid of the bug described below.During the execution of eb_lookup_vmas(), the eb->vma array issuccessively filled up with struct eb_vma objects. This process includescalling eb_add_vma(), which might fail; however, even in the event offailure, eb->vma[i].vma is set for the currently processed buffer.If eb_add_vma() fails, eb_lookup_vmas() returns with an error, whichprompts a call to eb_release_vmas() to clean up the mess. Sinceeb_lookup_vmas() might fail during processing any (possibly not first)buffer, eb_release_vmas() checks whether a buffer's vma is NULL to knowat what point did the lookup function fail.In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helperfunction eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma isset to NULL in case i915_gem_object_userptr_submit_init() fails; thecurrent one needs to be cleaned up by eb_release_vmas() at this point,so the next one is set. If eb_add_vma() fails, neither the current northe next vma is set to NULL, which is a source of a NULL deref bugdescribed in the issue linked in the Closes tag.When entering eb_lookup_vmas(), the vma pointers are set to the slabpoison value, instead of NULL. This doesn't matter for the actuallookup, since it gets overwritten anyway, however the eb_release_vmas()function only recognizes NULL as the stopping value, hence the pointersare being set to NULL as they go in case of intermediate failure. Thispatch changes the approach to filling them all with NULL at the startinstead, rather than handling that manually during failure.(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Do not use req->iv after crypto_aead_encryptAs soon as crypto_aead_encrypt is called, the underlying requestmay be freed by an asynchronous completion. Thus dereferencingreq->iv after it returns is invalid.Instead of checking req->iv against info, create a new variableunaligned_info and use it for that purpose instead.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: avoid invalid read in irdma_net_eventirdma_net_event() should not dereference anything from "neigh" (alias"ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.Other events come with different structures pointed to by "ptr" and theymay be smaller than struct neighbour.Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.The bug is mostly harmless, but it triggers KASAN on debug kernels: BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma] Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554 CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1 Hardware name: [...] Workqueue: events rt6_probe_deferred Call Trace: dump_stack_lvl+0x60/0xb0 print_address_description.constprop.0+0x2c/0x3f0 print_report+0xb4/0x270 kasan_report+0x92/0xc0 irdma_net_event+0x32e/0x3b0 [irdma] notifier_call_chain+0x9e/0x180 atomic_notifier_call_chain+0x5c/0x110 rt6_do_redirect+0xb91/0x1080 tcp_v6_err+0xe9b/0x13e0 icmpv6_notify+0x2b2/0x630 ndisc_redirect_rcv+0x328/0x530 icmpv6_rcv+0xc16/0x1360 ip6_protocol_deliver_rcu+0xb84/0x12e0 ip6_input_finish+0x117/0x240 ip6_input+0xc4/0x370 ipv6_rcv+0x420/0x7d0 __netif_receive_skb_one_core+0x118/0x1b0 process_backlog+0xd1/0x5d0 __napi_poll.constprop.0+0xa3/0x440 net_rx_action+0x78a/0xba0 handle_softirqs+0x2d4/0x9c0 do_softirq+0xad/0xe0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()It's possible for cp_read() and hdmi_read() to return -EIO. Thosevalues are further used as indexes for accessing arrays.Fix that by checking return values where it's needed.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"This patch ensures that the RX ring size (rx_pending) is notset below the permitted length. This avoids UBSANshift-out-of-bounds errors when users passes small or zeroring sizes via ethtool -G.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.32.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- iputils > 0-0 (version in image is 20221126-150500.3.14.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:mmc: core: use sysfs_emit() instead of sprintf()sprintf() (still used in the MMC core for the sysfs output) is vulnerableto the buffer overflow. Use the new-fangled sysfs_emit() instead.Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Remove device endpoints from bandwidth list when freeing the deviceEndpoints are normally deleted from the bandwidth list when they aredropped, before the virt device is freed.If xHC host is dying or being removed then the endpoints aren't droppedcleanly due to functions returning early to avoid interacting with anon-accessible host controller.So check and delete endpoints that are still on the bandwidth list whenfreeing the virt device.Solves a list_del corruption kernel crash when unbinding xhci-pci,caused by xhci_mem_cleanup() when it later tried to delete already freedendpoints from the bandwidth list.This only affects hosts that use software bandwidth checking, whichcurrenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: avoid double ->queue_rq() because of early timeoutDavid Jeffery found one double ->queue_rq() issue, so far it canbe triggered in VM use case because of long vmexit latency or preemptlatency of vCPU pthread or long page fault in vCPU pthread, then blockIO req could be timed out before queuing the request to hardware but aftercalling blk_mq_start_request() during ->queue_rq(), then timeout handlermay handle it by requeue, then double ->queue_rq() is caused, and kernelpanic.So far, it is driver's responsibility to cover the race between timeoutand completion, so it seems supposed to be solved in driver in theory,given driver has enough knowledge.But it is really one common problem, lots of driver could have similarissue, and could be hard to fix all affected drivers, even it isn't easyfor driver to handle the race. So David suggests this patch by drainingin-progress ->queue_rq() for solving this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: pch: Fix PCI device refcount leak in pch_request_dma()As comment of pci_get_slot() says, it returns a pci_device with itsrefcount increased. The caller must decrement the reference count bycalling pci_dev_put().Since 'dma_dev' is only used to filter the channel in filter(), we cancall pci_dev_put() before exiting from pch_request_dma(). Add themissing pci_dev_put() for the normal and error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: use proper req destructor for IPv6Before, only the destructor from TCP request sock in IPv4 was calledeven if the subflow was IPv6.It is important to use the right destructor to avoid memory leaks withsome advanced IPv6 features, e.g. when the request socks containspecific IPv6 options.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: avoid possible NULL deref in skb_clone()syzbot got a crash [1] in skb_clone(), caused by a bugin hsr_get_untagged_frame().When/if create_stripped_skb_hsr() returns NULL, we mustnot attempt to call skb_clone().While we are at it, replace a WARN_ONCE() by netdev_warn_once().[1]general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164hsr_forward_do net/hsr/hsr_forward.c:461 [inline]hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69__netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379__netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483__netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599netif_receive_skb_internal net/core/dev.c:5685 [inline]netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025call_write_iter include/linux/fs.h:2187 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x9e9/0xdd0 fs/read_write.c:584ksys_write+0x127/0x250 fs/read_write.c:637do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bcmgenet: Add a check for oversized packetsOccasionnaly we may get oversized packets from the hardware whichexceed the nomimal 2KiB buffer size we allocate SKBs with. Add an earlycheck which drops the packet to avoid invoking skb_over_panic() and moveon to processing the next packet.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix out of bounds access in DCCP error handlerThere was a previous attempt to fix an out-of-bounds access in the DCCPerror handlers, but that fix assumed that the error handlers only wantto access the first 8 bytes of the DCCP header. Actually, they also lookat the DCCP sequence number, which is stored beyond 8 bytes, so anexplicit pskb_may_pull() is required.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).
-
Description: A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).
-
Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix receive ring space parameters when XDP is activeThe MTU setting at the time an XDP multi-buffer is attacheddetermines whether the aggregation ring will be used and therx_skb_func handler. This is done in bnxt_set_rx_skb_mode().If the MTU is later changed, the aggregation ring setting may needto be changed and it may become out-of-sync with the settingsinitially done in bnxt_set_rx_skb_mode(). This may result inrandom memory corruption and crashes as the HW may DMA data largerthan the allocated buffer size, such as:BUG: kernel NULL pointer dereference, address: 00000000000003c0PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021RIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33fRSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ffRDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbfR10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en]To address the issue, we now call bnxt_set_rx_skb_mode() withinbnxt_change_mtu() to properly set the AGG rings configuration andupdate rx_skb_func based on the new MTU value.Additionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning ofbnxt_set_rx_skb_mode() to make sure it gets set or cleared based onthe current MTU.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix shift-out-of-bounds in dbSplitWhen dmt_budmin is less than zero, it causes errorsin the later stages. Added a check to return an error beforehandin dbAllocCtl itself.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:geneve: do not assume mac header is set in geneve_xmit_skb()We should not assume mac header is set in output path.Use skb_eth_hdr() instead of eth_hdr() to fix the issue.sysbot reported the following : WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Modules linked in:CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ffRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - add error check in the ahash_hmac_init functionThe ahash_init functions may return fails. The ahash_hmac_init shouldnot return ok when ahash_init returns error. For an example, ahash_initwill return -ENOMEM when allocation memory is error.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.69.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.69.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.69.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: cls_flow: validate TCA_FLOW_RSHIFT attributesyzbot found that TCA_FLOW_RSHIFT attribute was not validated.Right shitfing a 32bit integer is undefined for large shift values.UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: ipv6_addrconf addrconf_dad_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: fix truesize for mb-xdp-pass caseWhen mb-xdp is set and return is XDP_PASS, packet is converted fromxdp_buff to sk_buff with xdp_update_skb_shared_info() inbnxt_xdp_build_skb().bnxt_xdp_build_skb() passes incorrect truesize argument toxdp_update_skb_shared_info().The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags butthe skb_shared_info was wiped by napi_build_skb() before.So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use itinstead of getting skb_shared_info from xdp_get_shared_info_from_buff().Splat looks like: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590 Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3 RIP: 0010:skb_try_coalesce+0x504/0x590 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? __warn+0x84/0x130 ? skb_try_coalesce+0x504/0x590 ? report_bug+0x18a/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? skb_try_coalesce+0x504/0x590 inet_frag_reasm_finish+0x11f/0x2e0 ip_defrag+0x37a/0x900 ip_local_deliver+0x51/0x120 ip_sublist_rcv_finish+0x64/0x70 ip_sublist_rcv+0x179/0x210 ip_list_rcv+0xf9/0x130How to reproduce:ip link set $interface1 xdp obj xdp_pass.oip link set $interface1 mtu 9000 upip a a 10.0.0.1/24 dev $interface1ip link set $interfac2 mtu 9000 upip a a 10.0.0.2/24 dev $interface2ping 10.0.0.1 -s 65000Following ping.py patch adds xdp-mb-pass case. so ping.py is going to beable to reproduce this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix memory accounting leak.Matt Dowling reported a weird UDP memory usage issue.Under normal operation, the UDP memory usage reported in /proc/net/sockstatremains close to zero. However, it occasionally spiked to 524,288 pagesand never dropped. Moreover, the value doubled when the application wasterminated. Finally, it caused intermittent packet drops.We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577The application set INT_MAX to SO_RCVBUF, which triggered an integeroverflow in udp_rmem_release().When a socket is close()d, udp_destruct_common() purges its receivequeue and sums up skb->truesize in the queue. This total is calculatedand stored in a local unsigned integer variable.The total size is then passed to udp_rmem_release() to adjust memoryaccounting. However, because the function takes a signed integerargument, the total size can wrap around, causing an overflow.Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().When the issue occurred, the total in udp_destruct_common() was 2147484480(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and2) sets -2147479552 to amount. 3) reverts the wraparound, so we don'tsee a warning in inet_sock_destruct(). However, udp_memory_allocatedends up doubling at 4).Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves formemory_allocated"), memory usage no longer doubles immediately aftera socket is close()d because __sk_mem_reduce_allocated() caches theamount in udp_memory_per_cpu_fw_alloc. However, the next time a UDPsocket receives a packet, the subtraction takes effect, causing UDPmemory usage to double.This issue makes further memory allocation fail once the socket'ssk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packetdrops.To prevent this issue, let's use unsigned int for the calculation andcall sk_forward_alloc_add() only once for the small delta.Note that first_packet_length() also potentially has the same problem.[0]:from socket import *SO_RCVBUFFORCE = 33INT_MAX = (2 ** 31) - 1s = socket(AF_INET, SOCK_DGRAM)s.bind(('', 0))s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)c = socket(AF_INET, SOCK_DGRAM)c.connect(s.getsockname())data = b'a' * 100while True: c.send(data)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:usb: dwc3: gadget: check that event count does not exceed event buffer lengthThe event count is read from register DWC3_GEVNTCOUNT.There is a check for the count being zero, but not for exceeding theevent buffer length.Check that event count does not exceed event buffer length,avoiding an out-of-bounds access when memcpy'ing the event.Crash log:Unable to handle kernel paging request at virtual address ffffffc0129be000pc : __memcpy+0x114/0x180lr : dwc3_check_event_buf+0xec/0x348x3 : 0000000000000030 x2 : 000000000000dfc4x1 : ffffffc0129be000 x0 : ffffff87aad60080Call trace:__memcpy+0x114/0x180dwc3_interrupt+0x24/0x34
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problemCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis problem is similar to the problem that thecommit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")fixes.The root cause is: the function ib_device_rename() renames the name withlock. But in the function kobject_uevent(), this name is accessed withoutlock protection at the same time.The solution is to add the lock protection when this name is accessed inthe function kobject_uevent().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: remove encap socket caching to avoid reference leakThe current scheme for caching the encap socket can lead to referenceleaks when we try to delete the netns.The reference chain is: xfrm_state -> enacp_sk -> netnsSince the encap socket is a userspace socket, it holds a reference onthe netns. If we delete the espintcp state (through flush orindividual delete) before removing the netns, the reference on thesocket is dropped and the netns is correctly deleted. Otherwise, thenetns may not be reachable anymore (if all processes within the nshave terminated), so we cannot delete the xfrm state to drop itsreference on the socket.This patch results in a small (~2% in my tests) performanceregression.A GC-type mechanism could be added for the socket cache, to clearreferences if the state hasn't been used "recently", but it's a lotmore complex than just not caching the socket.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Abort software beacon handling if disabledA malicious USB device can send a WMI_SWBA_EVENTID event from anath9k_htc-managed device before beaconing has been enabled. This causesa device-by-zero error in the driver, leading to either a crash or anout of bounds read.Prevent this by aborting the handling in ath9k_htc_swba() if beacons arenot enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: marvell/cesa - Handle zero-length skcipher requestsDo not access random memory for zero-length skcipher requests.Just return 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_{g2h,h2g} TOCTOUvsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.transport_{g2h,h2g} may become NULL after the NULL check.Introduce vsock_transport_local_cid() to protect from a potentialnull-ptr-deref.KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_find_cid+0x47/0x90Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix initialization of data for instructions that write to subdeviceSome Comedi subdevice instruction handlers are known to accessinstruction data elements beyond the first `insn->n` elements in somecases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functionsallocate at least `MIN_SAMPLES` (16) data elements to deal with this,but they do not initialize all of that. For Comedi instruction codesthat write to the subdevice, the first `insn->n` data elements arecopied from user-space, but the remaining elements are leftuninitialized. That could be a problem if the subdevice instructionhandler reads the uninitialized data. Ensure that the first`MIN_SAMPLES` elements are initialized before calling these instructionhandlers, filling the uncopied elements with 0. For`do_insnlist_ioctl()`, the same data buffer elements are used forhandling a list of instructions, so ensure the first `MIN_SAMPLES`elements are initialized for each instruction that writes to thesubdevice.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized data in insn_rw_emulate_bits()For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have`insn_read` and `insn_write` handler functions, but to have an`insn_bits` handler function for handling Comedi `INSN_BITS`instructions. In that case, the subdevice's `insn_read` and/or`insn_write` function handler pointers are set to point to the`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that thesupplied `data[0]` value is a valid copy from user memory. It will atleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements areallocated. However, if `insn->n` is 0 (which is allowable for`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may containuninitialized data, and certainly contains invalid data, possibly from adifferent instruction in the array of instructions handled by`do_insnlist_ioctl()`. This will result in an incorrect value beingwritten to the digital output channel (or to the digital input/outputchannel if configured as an output), and may be reflected in theinternal saved state of the channel.Fix it by returning 0 early if `insn->n` is 0, before reaching the codethat accesses `data[0]`. Previously, the function always returned 1 onsuccess, but it is supposed to be the number of data samples actuallyread or written up to `insn->n`, which is 0 in this case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das6402: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das16m1: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix use-after-free caused by cyclic delayed workThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()to cancel the cyclic delayed work item ocelot->stats_work. However,cancel_delayed_work() may fail to cancel the work item if it is alreadyexecuting. While destroy_workqueue() does wait for all pending work itemsin the work queue to complete before destroying the work queue, it cannotprevent the delayed work item from being rescheduled within theocelot_check_stats_work() function. This limitation exists because thedelayed work item is only enqueued into the work queue after its timerexpires. Before the timer expiration, destroy_workqueue() has no visibilityof this pending work item. Once the work queue appears empty,destroy_workqueue() proceeds with destruction. When the timer eventuallyexpires, the delayed work item gets queued again, leading to the followingwarning:workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-statsWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0...RIP: 0010:__queue_work+0x875/0xaf0...RSP: 0018:ffff88806d108b10 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0Call Trace: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...The following diagram reveals the cause of the above warning:CPU 0 (remove) | CPU 1 (delayed work callback)mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAFThe above scenario actually constitutes a UAF vulnerability.The ocelot_stats_deinit() is only invoked when initializationfailure or resource destruction, so we must ensure that anydelayed work items cannot be rescheduled.Replace cancel_delayed_work() with disable_delayed_work_sync()to guarantee proper cancellation of the delayed work item andensure completion of any currently executing work before theworkqueue is deallocated.A deadlock concern was considered: ocelot_stats_deinit() is calledin a process context and is not holding any locks that the delayedwork item might also need. Therefore, the use of the _sync() variantis safe here.This bug was identified through static analysis. To reproduce theissue and validate the fix, I simulated ocelot-swit---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: bitblit: bound-check glyph index in bit_putcs*bit_putcs_aligned()/unaligned() derived the glyph pointer from thecharacter value masked by 0xff/0x1ff, which may exceed the actual font'sglyph count and read past the end of the built-in font array.Clamp the index to the actual glyph count before computing the address.This fixes a global out-of-bounds read reported by syzbot.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh < 8.4p1-150300.3.57.1 (version in image is 8.4p1-150300.3.49.1).
-
Description: ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- openssh < 8.4p1-150300.3.57.1 (version in image is 8.4p1-150300.3.49.1).
-
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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:f2fs: fix to detect potential corrupted nid in free_nid_listAs reported, on-disk footer.ino and footer.nid is the same andout-of-range, let's add sanity check on f2fs_alloc_nid() to detectany potential corruption in free_nid_list.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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.5 (version in image is 15.5-150500.43.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.1).
-
Description: Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glibc > 0-0 (version in image is 2.31-150300.95.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix incomplete validation of ioctl argWe tested and found an alarm caused by nbd_ioctl arg without verification.The UBSAN warning calltrace like below:UBSAN: Undefined behaviour in fs/buffer.c:1709:35signed integer overflow:-9223372036854775808 - 1 cannot be represented in type 'long long int'CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607 __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344The reason for triggering this warning is __block_write_full_page()-> i_size_read(inode) - 1 overflow.inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize.We think it is necessary to limit the size of arg to prevent errors.Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int.Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine),it will become 1 after the coercion, which will return unexpected results.Fix it by adding checks to prevent passing in too large numbers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc: fix uaf in proc_readdir_de()Pde is erased from subdir rbtree through rb_erase(), but not set the nodeto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()set the erased node to EMPTY, then pde_subdir_next() will return NULL toavoid uaf access.We found an uaf issue while using stress-ng testing, need to run testcasegetdent and tun in the same time. The steps of the issue is as follows:1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.CPU 0 | CPU 1-------------------------------------------------------------------------traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't trust firmware n_channelsIf the firmware sends us a corrupted MCC response withn_channels much larger than the command response can be,we might copy far too much (uninitialized) memory andeven crash if the n_channels is large enough to make itrun out of the one page allocated for the FW response.Fix that by checking the lengths. Doing a < comparisonwould be sufficient, but the firmware should be doingit correctly, so check more strictly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Fix crash due to uninitialized current_vmcsKVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running asa nested hypervisor on top of Hyper-V. When MSR bitmap is updated,evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to markthat the msr bitmap was changed.vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr-> vmx_msr_bitmap_l01_changed which in the end calls this function. Thefunction checks for current_vmcs if it is null but the check isinsufficient because current_vmcs is not initialized. Because of this, thecode might incorrectly write to the structure pointed by current_vmcs valueleft by another task. Preemption is not disabled, the current task can bepreempted and moved to another CPU while current_vmcs is accessed multipletimes from evmcs_touch_msr_bitmap() which leads to crash.The manipulation of MSR bitmaps by callers happens only for vmcs01 so thesolution is to use vmx->vmcs01.vmcs instead of current_vmcs. BUG: kernel NULL pointer dereference, address: 0000000000000338 PGD 4e1775067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI ... RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel] ... Call Trace: vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel] vmx_vcpu_create+0xe6/0x540 [kvm_intel] kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm] kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm] kvm_vm_ioctl+0x53f/0x790 [kvm] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: netem: account for backlog updates from child qdiscIn general, 'qlen' of any classful qdisc should keep track of thenumber of packets that the qdisc itself and all of its children holds.In case of netem, 'qlen' only accounts for the packets in its internaltfifo. When netem is used with a child qdisc, the child qdisc can use'qdisc_tree_reduce_backlog' to inform its parent, netem, about createdor dropped SKBs. This function updates 'qlen' and the backlog statisticsof netem, but netem does not account for changes made by a child qdisc.'qlen' then indicates the wrong number of packets in the tfifo.If a child qdisc creates new SKBs during enqueue and informs its parentabout this, netem's 'qlen' value is increased. When netem dequeues thenewly created SKBs from the child, the 'qlen' in netem is not updated.If 'qlen' reaches the configured sch->limit, the enqueue function stopsworking, even though the tfifo is not full.Reproduce the bug:Ensure that the sender machine has GSO enabled. Configure netem as rootqdisc and tbf as its child on the outgoing interface of the machineas follows:$ tc qdisc add dev root handle 1: netem delay 100ms limit 100$ tc qdisc add dev parent 1:0 tbf rate 50Mbit burst 1542 latency 50msSend bulk TCP traffic out via this interface, e.g., by running an iPerf3client on the machine. Check the qdisc statistics:$ tc -s qdisc show dev Statistics after 10s of iPerf3 TCP test before the fix (note thatnetem's backlog > limit, netem stopped accepting packets):qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0Statistics after the fix:qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.The interface fully stops transferring packets and "locks". In this case,the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is atits limit and no more packets are accepted.This patch adds a counter for the entries in the tfifo. Netem's 'qlen' isonly decreased when a packet is returned by its dequeue function, and notduring enqueuing into the child qdisc. External updates to 'qlen' are thusaccounted for and only the behavior of the backlog statistics changes. Asin other qdiscs, 'qlen' then keeps track of how many packets are held innetem and all of its children. As before, sch->limit remains as themaximum number of packets in the tfifo. The same applies to netem'sbacklog statistics.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()There are actually 2 problems:- deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds.- The memmove itself should move size - i - 1 elements, because the last element is out of bounds.The out-of-bounds element still remains out of bounds after beingaccessed, so the problem is only that we touch it, not that it becomesin active use. But I suppose it can lead to issues if the out-of-boundselement is part of an unmapped page.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: core: config: Prevent OOB read in SS endpoint companion parsingusb_parse_ss_endpoint_companion() checks descriptor type before length,enabling a potentially odd read outside of the buffer size.Fix this up by checking the size first before looking at any of thefields in the descriptor.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: remove read access to debugfs filesThe 'command' and 'netdev_ops' debugfs files are a legacy debugginginterface supported by the i40e driver since its early days by commit02e9c290814c ("i40e: debugfs interface").Both of these debugfs files provide a read handler which is mostly useless,and which is implemented with questionable logic. They both use a static256 byte buffer which is initialized to the empty string. In the case ofthe 'command' file this buffer is literally never used and simply wastesspace. In the case of the 'netdev_ops' file, the last command written issaved here.On read, the files contents are presented as the name of the devicefollowed by a colon and then the contents of their respective staticbuffer. For 'command' this will always be ": ". For 'netdev_ops',this will be ": ". But note the buffer isshared between all devices operated by this module. At best, it is mostlymeaningless information, and at worse it could be accessed simultaneouslyas there doesn't appear to be any locking mechanism.We have also recently received multiple reports for both read functionsabout their use of snprintf and potential overflow that could result inreading arbitrary kernel memory. For the 'command' file, this is definitelyimpossible, since the static buffer is always zero and never written to.For the 'netdev_ops' file, it does appear to be possible, if the usercarefully crafts the command input, it will be copied into the buffer,which could be large enough to cause snprintf to truncate, which thencauses the copy_to_user to read beyond the length of the buffer allocatedby kzalloc.A minimal fix would be to replace snprintf() with scnprintf() which wouldcap the return to the number of bytes written, preventing an overflow. Amore involved fix would be to drop the mostly useless static buffers,saving 512 bytes and modifying the read functions to stop needing those asinput.Instead, lets just completely drop the read access to these files. Theseare debug interfaces exposed as part of debugfs, and I don't believe thatdropping read access will break any script, as the provided output ispretty useless. You can find the netdev name through other more standardinterfaces, and the 'netdev_ops' interface can easily result in garbage ifyou issue simultaneous writes to multiple devices at once.In order to properly remove the i40e_dbg_netdev_ops_buf, we need torefactor its write function to avoid using the static buffer. Instead, usethe same logic as the i40e_dbg_command_write, with an allocated buffer.Update the code to use this instead of the static buffer, and ensure wefree the buffer on exit. This fixes simultaneous writes to 'netdev_ops' onmultiple devices, and allows us to remove the now unused static bufferalong with removing the read access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- containerd < 1.7.29-150000.128.1 (version in image is 1.7.27-150000.123.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: do not index invalid pin_assignmentsA poorly implemented DisplayPort Alt Mode port partner can indicatethat its pin assignment capabilities are greater than the maximumvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_showwill cause a BRK exception due to an out of bounds array access.Prevent for loop in pin_assignment_show from accessinginvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAXvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loopcondition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).
-
Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix unexpected zeroed page mapping with zram swapTwo processes under CLONE_VM cloning, user process can be corrupted byseeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed dataThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn'tincrease the refcount of swap slot at copy_mm so it couldn't catch upwhether it's safe or not to discard data from backing device. In thecase, only the lock it could rely on to synchronize swap slot freeing ispage table lock. Thus, this patch gets rid of the swap_slot_free_notifyfunction. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU BThe concern of the patch would increase memory consumption since itcould keep wasted memory with compressed form in zram as well asuncompressed form in address space. However, most of cases of zram usesno readahead and do_swap_page is followed by swap_free so it will freethe compressed form from in zram quickly.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: Restrict usage of GPIO chip irq members before initializationGPIO chip irq members are exposed before they could be completelyinitialized and this leads to race conditions.One such issue was observed for the gc->irq.domain variable whichwas accessed through the I2C interface in gpiochip_to_irq() beforeit could be initialized by gpiochip_add_irqchip(). This resulted inKernel NULL pointer dereference.Following are the logs for reference :-kernel: Call Trace:kernel: gpiod_to_irq+0x53/0x70kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0kernel: i2c_acpi_get_irq+0xc0/0xd0kernel: i2c_device_probe+0x28a/0x2a0kernel: really_probe+0xf2/0x460kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0To avoid such scenarios, restrict usage of GPIO chip irq members beforethey are completely initialized.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_prot_sock.sysctl_ip_prot_sock is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_llm_reports.While reading sysctl_igmp_llm_reports, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext2: Add more validity checks for inode countsAdd checks verifying number of inodes stored in the superblock matchesthe number computed from number of inodes per group. Also verify we haveat least one block worth of inodes per group. This prevents crashes oncorrupted filesystems.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix a race condition between login_work and the login threadIn case a malicious initiator sends some random data immediately after alogin PDU; the iscsi_target_sk_data_ready() callback will schedule thelogin_work and, at the same time, the negotiation may end without clearingthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges arerequired to complete the login).The login has been completed but the login_work function will find theLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from reschedulingitself; at this point, if the initiator drops the connection, theiscsit_conn structure will be freed, login_work will dereference a releasedsocket structure and the kernel crashes.BUG: kernel NULL pointer dereference, address: 0000000000000230PF: supervisor write access in kernel modePF: error_code(0x0002) - not-present pageWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]RIP: 0010:_raw_read_lock_bh+0x15/0x30Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0Fix this bug by forcing login_work to stop after the login has beencompleted and the socket callbacks have been restored.Add a comment to clearify the return values of iscsi_target_do_login()
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Clean up si_domain in the init_dmars() error pathA splat from kmem_cache_destroy() was seen with a kernel prior tocommit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")when there was a failure in init_dmars(), because the iommu_domaincache still had objects. While the mempool code is now gone, therestill is a leak of the si_domain memory if init_dmars() fails. Soclean up si_domain in the init_dmars() error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: fix memory leak in iio_device_register_eventset()When iio_device_register_sysfs_group() returns failed,iio_device_register_eventset() needs to free attrs array.Otherwise, kmemleak would scan & report memory leak as below:unreferenced object 0xffff88810a1cc3c0 (size 32): comm "100-i2c-vcnl302", pid 728, jiffies 4295052307 (age 156.027s) backtrace: __kmalloc+0x46/0x1b0 iio_device_register_eventset at drivers/iio/industrialio-event.c:541 __iio_device_register at drivers/iio/industrialio-core.c:1959 __devm_iio_device_register at drivers/iio/industrialio-core.c:2040
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: Fix device name leak when register device failed in add_mtd_device()There is a kmemleak when register device failed: unreferenced object 0xffff888101aab550 (size 8): comm "insmod", pid 3922, jiffies 4295277753 (age 925.408s) hex dump (first 8 bytes): 6d 74 64 30 00 88 ff ff mtd0.... backtrace: [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0 [<000000006e781163>] dev_set_name+0xab/0xe0 [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700 [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0 [<00000000c0d88488>] 0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0 [<00000000770f6ca6>] do_init_module+0xdf/0x320 [<000000007b6768fe>] load_module+0x2f98/0x3330 [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0 [<00000000674c2290>] do_syscall_64+0x35/0x80 [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0If register device failed, should call put_device() to give up thereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: call __btrfs_remove_free_space_cache_locked on cache load failureNow that lockdep is staying enabled through our entire CI runs I startedseeing the following stack in generic/475------------[ cut here ]------------WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014Workqueue: btrfs-cache btrfs_work_helperRIP: 0010:btrfs_discard_update_discardable+0x98/0xb0RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831eRBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock);We have a temporary free space ctl for loading the free space cache inorder to avoid having allocations happening while we're loading thecache. When we hit an error we free it all up, however this also callsbtrfs_discard_update_discardable, which requiresblock_group->free_space_ctl->tree_lock to be held. However this is ourtemporary ctl so this lock isn't held. Fix this by calling__btrfs_remove_free_space_cache_locked instead so that we only clean upthe entries and do not mess with the discardable stats.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: Fix memory leak in __ima_inode_hash()Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") letsmeasurement or audit happen even if the file digest cannot be calculated.As a result, iint->ima_hash could have been allocated despiteima_collect_measurement() returning an error.Since ima_hash belongs to a temporary inode metadata structure, declaredat the beginning of __ima_inode_hash(), just add a kfree() call ifima_collect_measurement() returns an error different from -ENOMEM (in thatcase, ima_hash should not have been allocated).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:class: fix possible memory leak in __class_register()If class_add_groups() returns error, the 'cp->subsys' need beunregister, and the 'cp' need be freed.We can not call kset_unregister() here, because the 'cls' willbe freed in callback function class_release() and it's alsofreed in caller's error path, it will cause double free.So fix this by calling kobject_del() and kfree_const(name) tocleanup kobject. Besides, call kfree() to free the 'cp'.Fault injection test can trigger this:unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49aunreferenced object 0xffff888037274000 (size 1024): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: adapt set backend to use GC transaction APIUse the GC transaction API to replace the old and buggy gc API and thebusy mark approach.No set elements are removed from async garbage collection anymore,instead the _DEAD bit is set on so the set element is not visible fromlookup path anymore. Async GC enqueues transaction work that might beaborted and retried later.rbtree and pipapo set backends does not set on the _DEAD bit from thesync GC path since this runs in control plane path where mutex is held.In this case, set elements are deactivated, removed and then releasedvia RCU callback, sync GC never fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this processThere are two states for ubifs writing pages:1. Dirty, Private2. Not Dirty, Not PrivateThe normal process cannot go to ubifs_releasepage() which means thereexists pages being private but not dirty. Reproducer[1] shows that itcould occur (which maybe related to [2]) with following process: PA PB PClock(page)[PA]ubifs_write_end attach_page_private // set Private __set_page_dirty_nobuffers // set Dirtyunlock(page)write_cache_pages[PA] lock(page) clear_page_dirty_for_io(page) // clear Dirty ubifs_writepage do_truncation[PB] truncate_setsize i_size_write(inode, newsize) // newsize = 0 i_size = i_size_read(inode) // i_size = 0 end_index = i_size >> PAGE_SHIFT if (page->index > end_index) goto out // jumpout:unlock(page) // Private, Not Dirty generic_fadvise[PC] lock(page) invalidate_inode_page try_to_release_page ubifs_releasepage ubifs_assert(c, 0) // bad assertion! unlock(page) truncate_pagecache[PB]Then we may get following assertion failed: UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]: UBIFS assert failed: 0, in fs/ubifs/file.c:1513 UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]: switched to read-only mode, error -22 CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308 Call Trace: dump_stack+0x13/0x1b ubifs_ro_mode+0x54/0x60 [ubifs] ubifs_assert_failed+0x4b/0x80 [ubifs] ubifs_releasepage+0x67/0x1d0 [ubifs] try_to_release_page+0x57/0xe0 invalidate_inode_page+0xfb/0x130 __invalidate_mapping_pages+0xb9/0x280 invalidate_mapping_pagevec+0x12/0x20 generic_fadvise+0x303/0x3c0 ksys_fadvise64_64+0x4c/0xb0[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: call kmem_cache_destroy() in dm_integrity_init() error pathOtherwise the journal_io_cache will leak if dm_register_target() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: fix memory leak of remain_skbshif_dev->remain_skb is allocated and used exclusively inath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb isprocessed and subsequently freed (in error paths) only during the nextcall of ath9k_hif_usb_rx_stream().So, if the urbs are deallocated between those two calls due to the devicedeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()is not called next time and the allocated remain_skb is leaked. Our localSyzkaller instance was able to trigger that.remain_skb makes sense when receiving two consecutive urbs which arelogically linked together, i.e. a specific data field from the first skbindicates a cached skb to be allocated, memcpy'd with some data andsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbsdeallocation supposedly makes that link irrelevant so we need to free thecached skb in those cases.Fix the leak by introducing a function to explicitly free remain_skb (ifit is not NULL) when the rx urbs have been deallocated. remain_skb is NULLwhen it has not been allocated at all (hif_dev struct is kzalloced) orwhen it has been processed in next call to ath9k_hif_usb_rx_stream().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix locking for runpm vs reclaimFor cases where icc_bw_set() can be called in callbaths that coulddeadlock against shrinker/reclaim, such as runpm resume, we need todecouple the icc locking. Introduce a new icc_bw_lock for cases wherewe need to serialize bw aggregation and update to decouple that frompaths that require memory allocation such as node/link creation/destruction.Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't free qgroup space unless specifiedBoris noticed in his simple quotas testing that he was getting a leakwith Sweet Tea's change to subvol create that stopped doing atransaction commit. This was just a side effect of that change.In the delayed inode code we have an optimization that will free extrareservations if we think we can pack a dir item into an already modifiedleaf. Previously this wouldn't be triggered in the subvolume createcase because we'd commit the transaction, it was still possible butmuch harder to trigger. It could actually be triggered if we did amkdir && subvol create with qgroups enabled.This occurs because in btrfs_insert_delayed_dir_index(), which getscalled when we're adding the dir item, we do the following: btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);if we're able to skip reserving space.The problem here is that trans->block_rsv points at the temporary blockrsv for the subvolume create, which has qgroup reservations in the blockrsv.This is a problem because btrfs_block_rsv_release() will do thefollowing: if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) { qgroup_to_release = block_rsv->qgroup_rsv_reserved - block_rsv->qgroup_rsv_size; block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size; }The temporary block rsv just has ->qgroup_rsv_reserved set,->qgroup_rsv_size == 0. The optimization inbtrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0. Thenlater on when we call btrfs_subvolume_release_metadata() which has btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release); btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);qgroup_to_release is set to 0, and we do not convert the reservedmetadata space.The problem here is that the block rsv code has been unconditionallymessing with ->qgroup_rsv_reserved, because the main place this is usedis delalloc, and any time we call btrfs_block_rsv_release() we do itwith qgroup_to_release set, and thus do the proper accounting.The subvolume code is the only other code that uses the qgroupreservation stuff, but it's intermingled with the above optimization,and thus was getting its reservation freed out from underneath it andthus leaking the reserved space.The solution is to simply not mess with the qgroup reservations if wedon't have qgroup_to_release set. This works with the existing code asanything that messes with the delalloc reservations always haveqgroup_to_release set. This fixes the leak that Boris was observing.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix blktrace debugfs entries leakageCommit 99d055b4fd4b ("block: remove per-disk debugfs files inblk_unregister_queue") moves blk_trace_shutdown() fromblk_release_queue() to blk_unregister_queue(), this is safe if blktraceis created through sysfs, however, there is a regression in cornercase.blktrace can still be enabled after del_gendisk() through ioctl ifthe disk is opened before del_gendisk(), and if blktrace is not shutdownthrough ioctl before closing the disk, debugfs entries will be leaked.Fix this problem by shutdown blktrace in disk_release(), this is safebecause blk_trace_remove() is reentrant.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix lockdep splat and potential deadlock after failure running delayed itemsWhen running delayed items we are holding a delayed node's mutex and thenwe will attempt to modify a subvolume btree to insert/update/delete thedelayed items. However if have an error during the insertions for example,btrfs_insert_delayed_items() may return with a path that has locked extentbuffers (a leaf at the very least), and then we attempt to release thedelayed node at __btrfs_run_delayed_items(), which requires taking thedelayed node's mutex, causing an ABBA type of deadlock. This was reportedby syzbot and the lockdep splat is the following: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted ------------------------------------------------------ syz-executor.2/13257 is trying to acquire lock: ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: __lock_release kernel/locking/lockdep.c:5475 [inline] lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline] btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239 search_leaf fs/btrfs/ctree.c:1986 [inline] btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline] btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline] __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flush_space+0x269/0xe70 fs/btrfs/space-info.c:723 btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix tags leak when shrink nr_hw_queuesAlthough we don't need to realloc set->tags[] when shrink nr_hw_queues,we need to free them. Or these tags will be leaked.How to reproduce:1. mount -t configfs configfs /mnt2. modprobe null_blk nr_devices=0 submit_queues=83. mkdir /mnt/nullb/nullb04. echo 1 > /mnt/nullb/nullb0/power5. echo 4 > /mnt/nullb/nullb0/submit_queues6. rmdir /mnt/nullb/nullb0In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), thenin step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).At last in step 6, only these 5 tags are freed, the other 4 tags leaked.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: fix memory leak after finding block group with super blocksAt exclude_super_stripes(), if we happen to find a block group that hassuper blocks mapped to it and we are on a zoned filesystem, we error outas this is not supposed to happen, indicating either a bug or maybe somememory corruption for example. However we are exiting the function withoutfreeing the memory allocated for the logical address of the super blocks.Fix this by freeing the logical address.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp_qoriq: fix memory leak in probe()Smatch complains that:drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()warn: 'base' from ioremap() not released.Fix this by revising the parameter from 'ptp_qoriq->base' to 'base'.This is only a bug if ptp_qoriq_init() returns on thefirst -ENODEV error path.For other error paths ptp_qoriq->base and base are the same.And this change makes the code more readable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- pam > 0-0 (version in image is 1.3.0-150000.6.86.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() when freeing tree block after errorWhen freeing a tree block, at btrfs_free_tree_block(), if we fail tocreate a delayed reference we don't deal with the error and just do aBUG_ON(). The error most likely to happen is -ENOMEM, and we have acomment mentioning that only -ENOMEM can happen, but that is not true,because in case qgroups are enabled any error returned frombtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returnedfrom btrfs_search_slot() for example) can be propagated back tobtrfs_free_tree_block().So stop doing a BUG_ON() and return the error to the callers and makethem abort the transaction to prevent leaking space. Syzbot wastriggering this, likely due to memory allocation failure injection.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Mask ring interrupts before ring stop requestBus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt whenthe ring is being stopped. Depending on timing between ring stop requestcompletion, interrupt handler removal and code execution this may leadto a NULL pointer dereference in hci_dma_irq_handler() if it gets to runafter the io_data pointer is set to NULL in hci_dma_cleanup().Prevent this my masking the ring interrupts before ring stop request.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: Use sequential access to access desc->pinmux dataWhen two client of the same gpio call pinctrl_select_state() for thesame functionality, we are seeing NULL pointer issue while accessingdesc->mux_owner.Let's say two processes A, B executing in pin_request() for the same pinand process A updates the desc->mux_usecount but not yet updated thedesc->mux_owner while process B see the desc->mux_usecount which gotupdated by A path and further executes strcmp and while accessingdesc->mux_owner it crashes with NULL pointer.Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B)pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } }
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make sure internal and UAPI bpf_redirect flags don't overlapThe bpf_redirect_info is shared between the SKB and XDP redirect paths,and the two paths use the same numeric flag values in the ri->flagsfield (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means thatif skb bpf_redirect_neigh() is used with a non-NULL params argument and,subsequently, an XDP redirect is performed using the samebpf_redirect_info struct, the XDP path will get confused and end upcrashing, which syzbot managed to trigger.With the stack-allocated bpf_redirect_info, the structure is no longershared between the SKB and XDP paths, so the crash doesn't happenanymore. However, different code paths using identically-numbered flagvalues in the same struct field still seems like a bit of a mess, sothis patch cleans that up by moving the flag definitions together andredefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlapwith the flags used for XDP. It also adds a BUILD_BUG_ON() check to makesure the overlap is not re-introduced by mistake.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/sve: Discard stale CPU state when handling SVE trapsThe logic for handling SVE traps manipulates saved FPSIMD/SVE stateincorrectly, and a race with preemption can result in a task havingTIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SVE traps enabled). This has been observed to resultin warnings from do_sve_acc() where SVE traps are not expected whileTIF_SVE is set:| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/The race can occur when the SVE trap handler is preempted before andafter manipulating the saved FPSIMD/SVE state, starting and ending onthe same CPU, e.g.| void do_sve_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */|| sve_init_regs() {| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| ...| } else {| fpsimd_to_sve(current);| current->thread.fp_type = FP_STATE_SVE;| }| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SVE traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: During unmount, ensure all cached dir instances drop their dentryThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) canrace with various cached directory operations, which ultimately resultsin dentries not being dropped and these kernel BUGs:BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]VFS: Busy inodes after unmount of cifs (cifs)------------[ cut here ]------------kernel BUG at fs/super.c:661!This happens when a cfid is in the process of being cleaned up when, andhas been removed from the cfids->entries list, including:- Receiving a lease break from the server- Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list- The laundromat thread decides to expire an old cfid.To solve these problems, dropping the dentry is done in queued work donein a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()flushes that workqueue after it drops all the dentries of which it'saware. This is a global workqueue (rather than scoped to a mount), butthe queued work is minimal.The final cleanup work for cleaning up a cfid is performed via workqueued in the serverclose_wq workqueue; this is done separate fromdropping the dentries so that close_all_cached_dirs() doesn't block onany server operations.Both of these queued works expect to invoked with a cfid reference anda tcon reference to avoid those objects from being freed while the workis ongoing.While we're here, add proper locking to close_all_cached_dirs(), andlocking around the freeing of cfid->dentry.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Don't leak cfid when reconnect races with open_cached_diropen_cached_dir() may either race with the tcon reconnection even beforecompound_send_recv() or directly trigger a reconnection viaSMB2_open_init() or SMB_query_info_init().The reconnection process invokes invalidate_all_cached_dirs() viacifs_mark_open_files_invalid(), which removes all cfids from thecfids->entries list but doesn't drop a ref if has_lease isn't true. Thisresults in the currently-being-constructed cfid not being on the list,but still having a refcount of 2. It leaks if returned fromopen_cached_dir().Fix this by setting cfid->has_lease when the ref is actually taken; thecfid will not be used by other threads until it has a valid time.Addresses these kmemleaks:unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] open_cached_dir+0x993/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eunreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eAnd addresses these BUG splats when unmounting the SMB filesystem:BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100Modules linked in:CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020RIP: 0010:umount_check+0xd0/0x100Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41RSP: 0018:ffff88811cc27978 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20baeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0Call Trace: d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f23bfb93ae7Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: IDLETIMER: Fix for possible ABBA deadlockDeletion of the last rule referencing a given idletimer may happen atthe same time as a read of its file in sysfs:| ======================================================| WARNING: possible circular locking dependency detected| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted| ------------------------------------------------------| iptables/3303 is trying to acquire lock:| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20|| but task is already holding lock:| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]|| which lock already depends on the new lock.A simple reproducer is:| #!/bin/bash|| while true; do| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| done &| while true; do| cat /sys/class/xt_idletimer/timers/testme >/dev/null| doneAvoid this by freeing list_mutex right after deleting the element fromthe list, then continuing with the teardown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cachefiles: Fix NULL pointer dereference in object->fileAt present, the object->file has the NULL pointer dereference problem inondemand-mode. The root cause is that the allocated fd and object->filelifetime are inconsistent, and the user-space invocation to anon_fd usesobject->file. Following is the process that triggers the issue: [write fd] [umount]cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...)Fix this issue by add an additional reference count to the object->filebefore write/llseek, and decrement after it finished.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu: Defer probe of clients after smmu device boundNull pointer dereference occurs due to a race between smmudriver probe and client driver probe, when of_dma_configure()for client is called after the iommu_device_register() for smmu driverprobe has executed but before the driver_bound() for smmu driverhas been called.Following is how the race occurs:T1:Smmu device probe T2: Client device probereally_probe()arm_smmu_device_probe()iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamid_mask */driver_bound() klist_add_tail()When this null smmu pointer is dereferenced later inarm_smmu_probe_device, the device crashes.Fix this by deferring the probe of the client deviceuntil the smmu device has bound to the arm smmu driver.[will: Add comment]
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:leds: class: Protect brightness_show() with led_cdev->led_access mutexThere is NULL pointer issue observed if from Process A where hid devicebeing added which results in adding a led_cdev addition and later aanother call to access of led_cdev attribute from Process B can resultin NULL pointer issue.Use mutex led_cdev->led_access to protect access to led->cdev and itsattribute inside brightness_show() and max_brightness_show() and alsoupdate the comment for mutex that it should be used to protect the ledclass device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 3313.874301][ T4013] Mem abort info:[ 3313.874303][ T4013] ESR = 0x0000000096000006[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits[ 3313.874307][ T4013] SET = 0, FnV = 0[ 3313.874309][ T4013] EA = 0, S1PTW = 0[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault[ 3313.874313][ T4013] Data abort info:[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000..[ 3313.874332][ T4013] Dumping ftrace buffer:[ 3313.874334][ T4013] (ftrace buffer empty)....[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60[ 3313.874656][ T4013] sp : ffffffc0b910bbd0....[ 3313.874685][ T4013] Call trace:[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74[ 3313.874690][ T4013] brightness_show+0x20/0x4c[ 3313.874692][ T4013] dev_attr_show+0x38/0x74[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8[ 3313.874711][ T4013] ksys_read+0x78/0xe8[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c[ 3313.874718][ T4013] invoke_syscall+0x58/0x114[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28[ 3313.874727][ T4013] el0_svc+0x38/0x68[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcsan: Turn report_filterlist_lock into a raw_spinlockRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can seesplats like:| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1| preempt_count: 10002, expected: 0| RCU nest depth: 0, expected: 0| no locks held by swapper/1/0.| irq event stamp: 156674| hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240| hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0| softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60| softirqs last disabled at (0): [<0000000000000000>] 0x0| Preemption disabled at:| [] paint_ptr+0x2a/0x90| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014| Call Trace:| | dump_stack_lvl+0x7e/0xc0| dump_stack+0x1d/0x30| __might_resched+0x1a2/0x270| rt_spin_lock+0x68/0x170| kcsan_skip_report_debugfs+0x43/0xe0| print_report+0xb5/0x590| kcsan_report_known_origin+0x1b1/0x1d0| kcsan_setup_watchpoint+0x348/0x650| __tsan_unaligned_write1+0x16d/0x1d0| hrtimer_interrupt+0x3d6/0x430| __sysvec_apic_timer_interrupt+0xe8/0x3a0| sysvec_apic_timer_interrupt+0x97/0xc0| On a detected data race, KCSAN's reporting logic checks if it shouldfilter the report. That list is protected by the report_filterlist_lock*non-raw* spinlock which may sleep on RT kernels.Since KCSAN may report data races in any context, convert it to araw_spinlock.This requires being careful about when to allocate memory for the filterlist itself which can be done via KCSAN's debugfs interface. Concurrentmodification of the filter list via debugfs should be rare: the chosenstrategy is to optimistically pre-allocate memory before the criticalsection and discard if unused.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Hold module reference while requesting a moduleUser space may unload ip_set.ko while it is itself requesting a set typebackend module, leading to a kernel crash. The race condition may beprovoked by inserting an mdelay() right after the nfnl_unlock() call.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointerConsidering that in some extreme cases,when u_serial driver is accessed by multiple threads,Thread A is executing the open operation and calling the gs_open,Thread B is executing the disconnect operation and calling thegserial_disconnect function,The port->port_usb pointer will be set to NULL.E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) CrashThis causes thread A to access a null pointer (port->port_usb is null)when calling the gs_free_requests function, causing a crash.If port_usb is NULL, the release request will be skipped as itwill be done by gserial_disconnect.So add a null pointer check to gs_start_io before attemptingto access the value of the pointer port->port_usb.Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: wl128x: Fix atomicity violation in fmc_send_cmd()Atomicity violation occurs when the fmc_send_cmd() function is executedsimultaneously with the modification of the fmdev->resp_skb value.Consider a scenario where, after passing the validity check within thefunction, a non-null fmdev->resp_skb variable is assigned a null value.This results in an invalid fmdev->resp_skb variable passing the validitycheck. As seen in the later part of the function, skb = fmdev->resp_skb;when the invalid fmdev->resp_skb passes the check, a null pointerdereference error may occur at line 478, evt_hdr = (void *)skb->data;To address this issue, it is recommended to include the validity check offmdev->resp_skb within the locked section of the function. Thismodification ensures that the value of fmdev->resp_skb does not changeduring the validation process, thereby maintaining its validity.This possible bug is found by an experimental static analysis tooldeveloped by our team. This tool analyzes the locking APIsto extract function pairs that can be concurrently executed, and thenanalyzes the instructions in the paired functions to identify possibleconcurrency bugs including data races and atomicity violations.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: Add check for rgby_data memory allocation failureIn ia_css_3a_statistics_allocate(), there is no check on the allocationresult of the rgby_data memory. If rgby_data is not successfullyallocated, it may trigger the assert(host_stats->rgby_data) assertion inia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.cAdd error pointer check after calling otx2_mbox_get_rsp().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:quota: flush quota_release_work upon quota writebackOne of the paths quota writeback is called from is:freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots()Since we currently don't always flush the quota_release_work queue inthis path, we can end up with the following race: 1. dquot are added to releasing_dquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quota_release_work queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state: ext4_journal_check_start+0x28/0x110 [ext4] (unreliable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0Which is the following line: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);Which ultimately results in generic/390 failing due to dmesgnoise. This was detected on powerpc machine 15 cores.To avoid this, make sure to flush the workqueue duringdquot_writeback_dquots() so we dont have any pending workitems afterfreeze.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: don't auto enable misc vectorCurrently, there is a time window between misc irq enabledand service task inited. If an interrupte is reported atthis time, it will cause warning like below:[ 16.324639] Call trace:[ 16.324641] __queue_delayed_work+0xb8/0xe0[ 16.324643] mod_delayed_work_on+0x78/0xd0[ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge][ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge][ 16.324666] __handle_irq_event_percpu+0x64/0x1e0[ 16.324667] handle_irq_event+0x80/0x170[ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc[ 16.324671] __handle_domain_irq+0x84/0xfc[ 16.324673] gic_handle_irq+0x88/0x2c0[ 16.324674] el1_irq+0xb8/0x140[ 16.324677] arch_cpu_idle+0x18/0x40[ 16.324679] default_idle_call+0x5c/0x1bc[ 16.324682] cpuidle_idle_call+0x18c/0x1c4[ 16.324684] do_idle+0x174/0x17c[ 16.324685] cpu_startup_entry+0x30/0x6c[ 16.324687] secondary_start_kernel+0x1a4/0x280[ 16.324688] ---[ end trace 6aa0bff672a964aa ]---So don't auto enable misc vector when request irq..
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: make get_first_thin use rcu-safe list first functionThe documentation in rculist.h explains the absence of list_empty_rcu()and cautions programmers against relying on a list_empty() ->list_first() sequence in RCU safe code. This is because each of thesefunctions performs its own READ_ONCE() of the list head. This can leadto a situation where the list_empty() sees a valid list entry, but thesubsequent list_first() sees a different view of list head state after amodification.In the case of dm-thin, this author had a production box crash from a GPfault in the process_deferred_bios path. This function saw a valid listhead in get_first_thin() but when it subsequently dereferenced that andturned it into a thin_c, it got the inside of the struct pool, since thelist was now empty and referring to itself. The kernel on which thisoccurred printed both a warning about a refcount_t being saturated, anda UBSAN error for an out-of-bounds cpuid access in the queued spinlock,prior to the fault itself. When the resulting kdump was examined, itwas possible to see another thread patiently waiting in thin_dtr'ssynchronize_rcu.The thin_dtr call managed to pull the thin_c out of the active thinslist (and have it be the last entry in the active_thins list) at justthe wrong moment which lead to this crash.Fortunately, the fix here is straight forward. Switch get_first_thin()function to use list_first_or_null_rcu() which performs just a singleREAD_ONCE() and returns NULL if the list is already empty.This was run against the devicemapper test suite's thin-provisioningsuites for delete and suspend and no regressions were observed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: discard packets if the transport changesIf the socket has been de-assigned or assigned to another transport,we must discard any packets received because they are not expectedand would cause issues when we access vsk->transport.A possible scenario is described by Hyunwoo Kim in the attached link,where after a first connect() interrupted by a signal, and a secondconnect() failed, we can find `vsk->transport` at NULL, leading to aNULL pointer dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: always recalculate features after XDP clearing, fix null-derefRecalculate features when XDP is detached.Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: onThe fact that HW-GRO doesn't get re-enabled automatically is justa minor annoyance. The real issue is that the features will randomlycome back during another reconfiguration which just happens to invokenetdev_update_features(). The driver doesn't handle reconfiguringtwo things at a time very robustly.Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") we only reconfigure the RSS hash tableif the "effective" number of Rx rings has changed. If HW-GRO isenabled "effective" number of rings is 2x what user sees.So if we are in the bad state, with HW-GRO re-enablement "pending"after XDP off, and we lower the rings by / 2 - the HW-GRO ringsdoing 2x and the ethtool -L doing / 2 may cancel each other out,and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings &&condition in __bnxt_reserve_rings() will be false.The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0As we try to access a freed ring.The issue is present since XDP support was added, really, butprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") it wasn't causing major issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: xilinx: Convert gpio_lock to raw spinlockirq_chip functions may be called in raw spinlock context. Therefore, wemust also use a raw spinlock for our own internal locking.This fixes the following lockdep splat:[ 5.349336] =============================[ 5.353349] [ BUG: Invalid wait context ][ 5.357361] 6.13.0-rc5+ #69 Tainted: G W[ 5.363031] -----------------------------[ 5.367045] kworker/u17:1/44 is trying to lock:[ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.380079] other info that might help us debug this:[ 5.385138] context-{5:5}[ 5.387762] 5 locks held by kworker/u17:1/44:[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)[ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)[ 5.436472] stack backtrace:[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69[ 5.448690] Tainted: [W]=WARN[ 5.451656] Hardware name: xlnx,zynqmp (DT)[ 5.455845] Workqueue: events_unbound deferred_probe_work_func[ 5.461699] Call trace:[ 5.464147] show_stack+0x18/0x24 C[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)[ 5.471501] dump_stack (lib/dump_stack.c:130)[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)[ 5.497645] irq_startup (kernel/irq/chip.c:270)[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: aggregator: protect driver attr handlers against module unloadBoth new_device_store and delete_device_store touch module globalresources (e.g. gpio_aggregator_lock). To prevent race conditions withmodule unload, a reference needs to be held.Add try_module_get() in these handlers.For new_device_store, this eliminates what appears to be the most dangerousscenario: if an id is allocated from gpio_aggregator_idr butplatform_device_register has not yet been called or completed, a concurrentmodule unload could fail to unregister/delete the device, leaving behind adangling platform device/GPIO forwarder. This can result in various issues.The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: streamzap: fix race between device disconnection and urb callbackSyzkaller has reported a general protection fault at functionir_raw_event_store_with_filter(). This crash is caused by a NULL pointerdereference of dev->raw pointer, even though it is checked for NULL inthe same function, which means there is a race condition. It occurs dueto the incorrect order of actions in the streamzap_disconnect() function:rc_unregister_device() is called before usb_kill_urb(). The dev->rawpointer is freed and set to NULL in rc_unregister_device(), and onlyafter that usb_kill_urb() waits for in-progress requests to finish.If rc_unregister_device() is called while streamzap_callback() handler isnot finished, this can lead to accessing freed resources. Thusrc_unregister_device() should be called after usb_kill_urb().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holdingthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock(through crypto_exit_scomp_ops_async()).On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (throughcrypto_scomp_init_tfm()), and then allocates memory. If the allocationresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.The above dependencies can cause an ABBA deadlock. For example in thefollowing scenario:(1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1)(2) Task A is descheduled(3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock(4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCKSince there is no requirement to call crypto_free_acomp() with the per-CPUacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex isunlocked. Also move the acomp_request_free() and kfree() calls forconsistency and to avoid any potential sublte locking dependencies in thefuture.With this, only setting acomp_ctx fields to NULL occurs with the mutexheld. This is similar to how zswap_cpu_comp_prepare() only initializesacomp_ctx fields with the mutex held, after performing all allocationsbefore holding the mutex.Opportunistically, move the NULL check on acomp_ctx so that it takes placebefore the mutex dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix adapter NULL pointer dereference on rebootWith SRIOV enabled, idpf ends up calling into idpf_remove() twice.First via idpf_shutdown() and then again when idpf_remove() calls intosriov_disable(), because the VF devices use the idpf driver, hence thesame remove routine. When that happens, it is possible for the adapterto be NULL from the first call to idpf_remove(), leading to a NULLpointer dereference.echo 1 > /sys/class/net//device/sriov_numvfsrebootBUG: kernel NULL pointer dereference, address: 0000000000000020...RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]...? idpf_remove+0x22/0x1f0 [idpf]? idpf_remove+0x1e4/0x1f0 [idpf]pci_device_remove+0x3f/0xb0device_release_driver_internal+0x19f/0x200pci_stop_bus_device+0x6d/0x90pci_stop_and_remove_bus_device+0x12/0x20pci_iov_remove_virtfn+0xbe/0x120sriov_disable+0x34/0xe0idpf_sriov_configure+0x58/0x140 [idpf]idpf_remove+0x1b9/0x1f0 [idpf]idpf_shutdown+0x12/0x30 [idpf]pci_device_shutdown+0x35/0x60device_shutdown+0x156/0x200...Replace the direct idpf_remove() call in idpf_shutdown() withidpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which performthe bulk of the cleanup, such as stopping the init task, freeing IRQs,destroying the vports and freeing the mailbox. This avoids the calls tosriov_disable() in addition to a small netdev cleanup, and destroyingworkqueues, which don't seem to be required on shutdown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pm: cpupower: bench: Prevent NULL dereference on malloc failureIf malloc returns NULL due to low memory, 'config' pointer can be NULL.Add a check to prevent NULL dereference.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix mode1 reset crash issueIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signaluser space to abort the processes. After process abort exit, user queuesstill use the GPU to access system memory before h/w is reset while KFDcleanup worker free system memory and free VRAM.There is use-after-free race bug that KFD allocate and reuse the freedsystem memory, and user queue write to the same system memory to corruptthe data structure and cause driver crash.To fix this race, KFD cleanup worker terminate user queues, then flushreset_domain wq to wait for any GPU ongoing reset complete, and thenfree outstanding BOs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: harden block_group::bg_list against list_del() racesAs far as I can tell, these calls of list_del_init() on bg_list cannotrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),as they are in transaction error paths and situations where the blockgroup is readonly.However, if there is any chance at all of racing with mark_bg_unused(),or a different future user of bg_list, better to be safe than sorry.Otherwise we risk the following interleaving (bg_list refcount in parens)T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1)list_del_init(&bg->bg_list); (1) list_move_tail (1)btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1)Ultimately, this results in a broken ref count that hits zero one derefearly and the real final deref underflows the refcount, resulting in a WARNING.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix deadlock between rcu_tasks_trace and event_mutex.Fix the following deadlock:CPU A_free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace()There are several paths where _free_event() grabs event_mutexand calls sync_rcu_tasks_trace. Above is one such case.CPU Bbpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex)Delegate trace_set_clr_event() to workqueue to avoidsuch lock dependency.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: inftlcore: Add error check for inftl_read_oob()In INFTL_findwriteunit(), the return value of inftl_read_oob()need to be checked. A proper implementation can befound in INFTL_deleteblock(). The status will be set asSECTOR_IGNORE to break from the while-loop correctlyif the inftl_read_oob() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-bufio: don't schedule in atomic contextA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP andtry_verify_in_tasklet are enabled.[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4[ 129.444740][ T934] preempt_count: 201, expected: 0[ 129.444756][ T934] RCU nest depth: 0, expected: 0[ 129.444781][ T934] Preemption disabled at:[ 129.444789][ T934] [] shrink_work+0x21c/0x248[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16![ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug][ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c[ 129.447451][ T934] sp : ffffffc0843dbc90[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000[ 129.447647][ T934] Call trace:[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6][ 129.447681][ T934] __might_resched+0x190/0x1a8[ 129.447694][ T934] shrink_work+0x180/0x248[ 129.447706][ T934] process_one_work+0x260/0x624[ 129.447718][ T934] worker_thread+0x28c/0x454[ 129.447729][ T934] kthread+0x118/0x158[ 129.447742][ T934] ret_from_fork+0x10/0x20[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---dm_bufio_lock will call spin_lock_bh when try_verify_in_taskletis enabled, and __scan will be called in atomic context.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Add job to pending list if the reset was skippedWhen a CL/CSD job times out, we check if the GPU has made any progresssince the last timeout. If so, instead of resetting the hardware, we skipthe reset and let the timer get rearmed. This gives long-running jobs achance to complete.However, when `timedout_job()` is called, the job in question is removedfrom the pending list, which means it won't be automatically freed through`free_job()`. Consequently, when we skip the reset and keep the jobrunning, the job won't be freed when it finally completes.This situation leads to a memory leak, as exposed in [1] and [2].Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler whenGPU is still active"), this patch ensures the job is put back on thepending list when extending the timeout.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qibfs: fix _another_ leakfailure to allocate inode => leaked dentry...this one had been there since the initial merge; to be fair,if we are that far OOM, the odds of failing at that particularallocation are low...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notifyDuring our test, it is found that a warning can be trigger in try_grab_folioas follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---Digging into the source, context->notify_page may init by get_user_pages_fastand can be seen in vmci_ctx_unset_notify which will try to put_page. Howeverget_user_pages_fast is not finished here and lead to followingtry_grab_folio warning. The race condition is shown as follow:cpu0 cpu1vmci_host_do_set_notifyvmci_host_setup_notifyget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);lockless_pages_from_mmgup_pgd_rangegup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed__gup_longterm_locked__get_user_pagesfollow_trans_huge_pmdtry_grab_folio // warn hereTo slove this, use local variable page to make notify_page can be seenafter finish get_user_pages_fast.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Kill timer properly at removalThe USB-audio MIDI code initializes the timer, but in a rare case, thedriver might be freed without the disconnect call. This leaves thetimer in an active state while the assigned object is released viasnd_usbmidi_free(), which ends up with a kernel warning when the debugconfiguration is enabled, as spotted by fuzzer.For avoiding the problem, put timer_shutdown_sync() atsnd_usbmidi_free(), so that the timer can be killed properly.While we're at it, replace the existing timer_delete_sync() at thedisconnect callback with timer_shutdown_sync(), too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: fix a race in ets_qdisc_change()Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: red: fix a race in __red_change()Gerrard Tai reported a race condition in RED, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix TOCTOU issue in sk_is_readable()sk->sk_prot->sock_is_readable is a valid function pointer when sk residesin a sockmap. After the last sk_psock_put() (which usually happens whensocket is removed from sockmap), sk->sk_prot gets restored andsk->sk_prot->sock_is_readable becomes NULL.This makes sk_is_readable() racy, if the value of sk->sk_prot is reloadedafter the initial check. Which in turn may lead to a null pointerdereference.Ensure the function pointer does not turn NULL after the check.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring timestampingThe stmmac platform drivers that do not open-code the clk_ptp_rate valueafter having retrieved the default one from the device-tree can end upwith 0 in clk_ptp_rate (as clk_get_rate can return 0). It willeventually propagate up to PTP initialization when bringing up theinterface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)Prevent this division by 0 by adding an explicit check and error logabout the actual issue. While at it, remove the same check fromstmmac_ptp_register, which then becomes duplicate
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix null-ptr-deref in jfs_ioc_trim[ Syzkaller Report ]Oops: general protection fault, probably for non-canonical address0xdffffc0000000087: 0000 [#1KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted6.13.0-rc6-gfbfd64d25c7a-dirty #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Sched_ext: serialise (enabled+all), task: runnable_at=-30msRIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:? __die_body+0x61/0xb0? die_addr+0xb1/0xe0? exc_general_protection+0x333/0x510? asm_exc_general_protection+0x26/0x30? jfs_ioc_trim+0x34b/0x8f0jfs_ioctl+0x3c8/0x4f0? __pfx_jfs_ioctl+0x10/0x10? __pfx_jfs_ioctl+0x10/0x10__se_sys_ioctl+0x269/0x350? __pfx___se_sys_ioctl+0x10/0x10? do_syscall_64+0xfb/0x210do_syscall_64+0xee/0x210? syscall_exit_to_user_mode+0x1e0/0x330entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe51f4903adCode: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 4889 f7 48 89 d6 48 89 ca 4dRSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903adRDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Kernel panic - not syncing: Fatal exception[ Analysis ]We believe that we have found a concurrency bug in the `fs/jfs` modulethat results in a null pointer dereference. There is a closely relatedissue which has been fixed:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... but, unfortunately, the accepted patch appears to still besusceptible to a null pointer dereference under some interleavings.To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is setto NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. Thisbug manifests quite rarely under normal circumstances, but istriggereable from a syz-program.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Initialize ssc before laundromat_work to prevent NULL dereferenceIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc throughnfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized,this can cause NULL pointer dereference.Normally the delayed start of laundromat_work allows sufficient time fornfsd_ssc initialization to complete. However, when the kernel waits toolong for userspace responses (e.g. in nfs4_state_start_net ->nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done ->cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), thedelayed work may start before nfsd_ssc initialization finishes.Fix this by moving nfsd_ssc initialization before starting laundromat_work.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.16.0-rc3-build2+ #1301 Tainted: G S W------------------------------------------------------cifsd/6055 is trying to acquire lock:ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30other info that might help us debug this:Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK ***3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix use-after-free in vhci_flush()syzbot reported use-after-free in vhci_flush() without repro. [0]From the splat, a thread close()d a vhci file descriptor whileits device was being used by iotcl() on another thread.Once the last fd refcnt is released, vhci_release() callshci_unregister_dev(), hci_free_dev(), and kfree() for structvhci_data, which is set to hci_dev->dev->driver_data.The problem is that there is no synchronisation after unlinkinghdev from hci_dev_list in hci_unregister_dev(). There might beanother thread still accessing the hdev which was fetched beforethe unlink operation.We can use SRCU for such synchronisation.Let's run hci_dev_reset() under SRCU and wait for its completionin hci_unregister_dev().Another option would be to restore hci_dev->destruct(), which wasremoved in commit 587ae086f6e4 ("Bluetooth: Remove unusedhci-destruct cb"). However, this would not be a good solution, aswe should not run hci_unregister_dev() while there are in-flightioctl() requests, which could lead to another data-race KCSAN splat.Note that other drivers seem to have the same problem, for exmaple,virtbt_remove().[0]:BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fcf5b98e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix node corruption in ar->arvifs listIn current WLAN recovery code flow, ath11k_core_halt() onlyreinitializes the "arvifs" list head. This will cause thelist node immediately following the list head to become aninvalid list node. Because the prev of that node still pointsto the list head "arvifs", but the next of the list head "arvifs"no longer points to that list node.When a WLAN recovery occurs during the execution of a vifremoval, and it happens before the spin_lock_bh(&ar->data_lock)in ath11k_mac_op_remove_interface(), list_del() will detect thepreviously mentioned situation, thereby triggering a kernel panic.The fix is to remove and reinitialize all vif list nodes from thelist head "arvifs" during WLAN halt. The reinitialization is to makethe list nodes valid, ensuring that the list_del() inath11k_mac_op_remove_interface() can execute normally.Call trace:__list_del_entry_valid_or_report+0xb8/0xd0ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]drv_remove_interface+0x48/0x194 [mac80211]ieee80211_do_stop+0x6e0/0x844 [mac80211]ieee80211_stop+0x44/0x17c [mac80211]__dev_close_many+0xac/0x150__dev_change_flags+0x194/0x234dev_change_flags+0x24/0x6cdevinet_ioctl+0x3a0/0x670inet_ioctl+0x200/0x248sock_do_ioctl+0x60/0x118sock_ioctl+0x274/0x35c__arm64_sys_ioctl+0xac/0xf0invoke_syscall+0x48/0x114...Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gpu: Fix crash when throttling GPU immediately during bootThere is a small chance that the GPU is already hot during boot. In thatcase, the call to of_devfreq_cooling_register() will immediately try toapply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ...At this point we haven't initialized the GMU at all yet, so we cannot readthe GMU registers inside a6xx_gpu_busy(). A similar issue was fixed beforein commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), butunlike msm_devfreq_suspend(), it doesn't set the df->suspended flagaccordingly. This means the df->suspended flag does not match the actualdevfreq state after initialization and msm_devfreq_get_dev_status() willend up accessing GMU registers, causing the crash.Fix this by setting df->suspended correctly during initialization.Patchwork: https://patchwork.freedesktop.org/patch/650772/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insertThe obj_event may be loaded immediately after inserted, then if thelist_head is not initialized then we may get a poisonous pointer. Thisfixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAINWe found a few different systems hung up in writeback waiting on the samepage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit inpnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding countwas zero.It seems most likely that this is another race between the waiter and wakersimilar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").Fix it up by applying the advised barrier.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: ims-pcu - check record size in ims_pcu_flash_firmware()The "len" variable comes from the firmware and we generally dotrust firmware, but it's always better to double check. If the "len"is too large it could result in memory corruption when we do"memcpy(fragment->data, rec->data, len);"
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_* TOCTOUTransport assignment may race with module unload. Protect new_transportfrom becoming a stale pointer.This also takes care of an insecure call in vsock_use_local_transport();add a lockdep assert.BUG: unable to handle page fault for address: fffffbfff8056000Oops: Oops: 0000 [#1] SMP KASANRIP: 0010:vsock_assign_transport+0x366/0x600Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: exynos7_drm_decon: add vblank check in IRQ handlingIf there's support for another console device (such as a TTY serial),the kernel occasionally panics during boot. The panic message and arelevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...]Otherwise, the panics don't happen. This indicates that it's some sortof race condition.Add a check to validate if the drm device can handle vblanks beforecalling drm_crtc_handle_vblank() to avoid this.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]l2cap_sock_resume_cb() has a similar problem that was fixed by commit1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executedunder l2cap_sock_resume_cb(), we can avoid the issue simply by checkingif chan->data is NULL.Let's not access to the killed socket in l2cap_sock_resume_cb().[0]:BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Workqueue: hci0 hci_rx_workCall trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: skbprio: Remove overly strict queue assertionsIn the current implementation, skbprio enqueue/dequeue contains an assertionthat fails under certain conditions when SKBPRIO is used as a child qdisc underTBF with specific parameters. The failure occurs because TBF sometimes peeks atpackets in the child qdisc without actually dequeuing them when tokens areunavailable.This peek operation creates a discrepancy between the parent and child qdiscqueue length counters. When TBF later receives a high-priority packet,SKBPRIO's queue length may show a different value than what's reflected in itsinternal priority queue tracking, triggering the assertion.The fix removes this overly strict assertions in SKBPRIO, they are notnecessary at all.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lockWhen netpoll is enabled, calling pr_warn_once() while holdingkmemleak_lock in mem_pool_alloc() can cause a deadlock due to lockinversion with the netconsole subsystem. This occurs becausepr_warn_once() may trigger netpoll, which eventually leads to__alloc_skb() and back into kmemleak code, attempting to reacquirekmemleak_lock.This is the path for the deadlock.mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);Fix this by setting a flag and issuing the pr_warn_once() afterkmemleak_lock is released.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix NULL pointer dereference in __dm_suspend()There is a race condition between dm device suspend and table load thatcan lead to null pointer dereference. The issue occurs when suspend isinvoked before table load completes:BUG: kernel NULL pointer dereference, address: 0000000000000054Oops: 0000 [#1] PREEMPT SMP PTICPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0The issue can be triggered as below:T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1)dm_stop_queue / dm_wait_for_completion=> q->tag_set NULL pointer! (2) => q->tag_set = set; (3)Fix this by checking if a valid table (map) exists before performingrequest-based suspend and waiting for target I/O. When map is NULL,skip these table-dependent suspend steps.Even when map is NULL, no I/O can reach any target because there isno table loaded; I/O submitted in this state will fail early in theDM layer. Skipping the table-dependent suspend logic in this caseis safe and avoids NULL pointer dereferences.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: client: fix memory leak in smb3_fs_context_parse_paramThe user calls fsconfig twice, but when the program exits, free() onlyfrees ctx->source for the second fsconfig, not the first.Regarding fc->source, there is no code in the fs context related to itsmemory reclamation.To fix this memory leak, release the source memory corresponding to ctxor fc before each parsing.syzbot reported:BUG: memory leakunreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444BUG: memory leakunreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Fix synchronous external abort on unbindA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind isexecuted after the configuration sequence described above:modprobe usb_f_ecmmodprobe libcompositemodprobe configfscd /sys/kernel/config/usb_gadgetmkdir -p g1cd g1echo "0x1d6b" > idVendorecho "0x0104" > idProductmkdir -p strings/0x409echo "0123456789" > strings/0x409/serialnumberecho "Renesas." > strings/0x409/manufacturerecho "Ethernet Gadget" > strings/0x409/productmkdir -p functions/ecm.usb0mkdir -p configs/c.1mkdir -p configs/c.1/strings/0x409echo "ECM" > configs/c.1/strings/0x409/configurationif [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1fiecho 11e20000.usb > UDCecho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbindThe displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1The issue occurs because usbhs_sys_function_pullup(), which accesses the IPregisters, is executed after the USBHS clocks have been disabled. Theproblem is reproducible on the Renesas RZ/G3S SoC starting with theaddition of module stop in the clock enable/disable APIs. With module stopfunctionality enabled, a bus error is expected if a master accesses amodule whose clock has been stopped and module stop activated.Disable the IP clocks at the end of remove.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Fix timeout handlingWhen the CPU that the QSPI interrupt handler runs on (typically CPU 0)is excessively busy, it can lead to rare cases of the IRQ thread notrunning before the transfer timeout is reached.While handling the timeouts, any pending transfers are cleaned up andthe message that they correspond to is marked as failed, which leavesthe curr_xfer field pointing at stale memory.To avoid this, clear curr_xfer to NULL upon timeout and check for thiscondition when the IRQ thread is finally run.While at it, also make sure to clear interrupts on failure so that newinterrupts can be run.A better, more involved, fix would move the interrupt clearing into ahard IRQ handler. Ideally we would also want to signal that the IRQthread no longer needs to be run after the timeout is hit to avoid theextra check for a valid transfer.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating compression context during writebackBai, Shuangpeng reported a bug as below:Oops: divide error: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857Call Trace: f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline] f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317 do_writepages+0x38e/0x640 mm/page-writeback.c:2634 filemap_fdatawrite_wbc mm/filemap.c:386 [inline] __filemap_fdatawrite_range mm/filemap.c:419 [inline] file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794 f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294 generic_write_sync include/linux/fs.h:3043 [inline] f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x7e9/0xe00 fs/read_write.c:686 ksys_write+0x19d/0x2d0 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe bug was triggered w/ below race condition:fsync setattr ioctl- f2fs_do_sync_file - file_write_and_wait_range - f2fs_write_cache_pages : inode is non-compressed : cc.cluster_size = F2FS_I(inode)->i_cluster_size = 0 - tag_pages_for_writeback - f2fs_setattr - truncate_setsize - f2fs_truncate - f2fs_fileattr_set - f2fs_setflags_common - set_compress_context : F2FS_I(inode)->i_cluster_size = 4 : set_inode_flag(inode, FI_COMPRESSED_FILE) - f2fs_compressed_file : return true - f2fs_all_cluster_page_ready : "pgidx % cc->cluster_size" trigger dividing 0 issueLet's change as below to fix this issue:- introduce a new atomic type variable .writeback in structure f2fs_inode_infoto track the number of threads which calling f2fs_write_cache_pages().- use .i_sem lock to protect .writeback update.- check .writeback before update compression context in f2fs_setflags_common()to avoid race w/ ->writepages.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_createWhen sync() and link() are called concurrently, both threads mayenter hfs_bnode_find() without finding the node in the hash tableand proceed to create it.Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it.Thread B also tries to create the same bnode, notices it has alreadybeen inserted, drops its own instance, and uses the hashed one withoutgetting the node.``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; }```However, hfs_bnode_find() requires each call to take a reference.Here both threads end up setting refcnt=1. When they later put the node,this triggers:BUG_ON(!atomic_read(&node->refcnt))In this scenario, Thread B in fact finds the node in the hash tablerather than creating a new one, and thus must take a reference.Fix this by calling hfs_bnode_get() when reusing a bnode newly created byanother thread to ensure the refcount is updated correctly.A similar bug was fixed in HFS long ago in commita9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")but the same issue remained in HFS+ until now.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (ibmpex) fix use-after-free in high/low storeThe ibmpex_high_low_store() function retrieves driver data usingdev_get_drvdata() and uses it without validation. This creates a racecondition where the sysfs callback can be invoked after the datastructure is freed, leading to use-after-free.Fix by adding a NULL check after dev_get_drvdata(), and reorderingoperations in the deletion path to prevent TOCTOU.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/amd: Check event before enable to avoid GPFOn AMD machines cpuc->events[idx] can become NULL in a subtle racecondition with NMI->throttle->x86_pmu_stop().Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.This appears to be an AMD only issue.Syzkaller reported a GPF in amd_pmu_enable_all.INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecsOops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzkRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430)RSP: 0018:ffff888118009d60 EFLAGS: 00010012RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0Call Trace: amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))x86_pmu_enable (arch/x86/events/core.c:1360)event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346)__perf_remove_from_context (kernel/events/core.c:2435)event_function (kernel/events/core.c:259)remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1))__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540)__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47))
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: xattr: fix null pointer deref in ext4_raw_inode()If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()lacks error checking, this will lead to a null pointer dereferencein ext4_raw_inode(), called right after ext4_get_inode_loc().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: fix use-after-free on probe deferralThe driver is dropping the references taken to the larb devices duringprobe after successful lookup as well as on errors. This canpotentially lead to a use-after-free in case a larb device has not yetbeen bound to its driver so that the iommu driver probe defers.Fix this by keeping the references as expected while the iommu driver isbound.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix reference count leak when using error routes with nexthop objectsWhen a nexthop object is deleted, it is marked as dead and thenfib_table_flush() is called to flush all the routes that are using thedead nexthop.The current logic in fib_table_flush() is to only flush error routes(e.g., blackhole) when it is called as part of network namespacedismantle (i.e., with flush_all=true). Therefore, error routes are notflushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1As such, they keep holding a reference on the nexthop object which inturn holds a reference on the nexthop device, resulting in a referencecount leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2Fix by flushing error routes when their nexthop is marked as dead.IPv6 does not suffer from this problem.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.9.1).
-
Description: containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.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:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can'tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm->nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1("cdc-acm: reassemble fragmented notifications").A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device's vendor/product IDs andits other interfaces.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()Robert Morris reported:|If a malicious USB device pretends to be an Intersil p54 wifi|interface and generates an eeprom_readback message with a large|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the|message beyond the end of priv->eeprom.||static void p54_rx_eeprom_readback(struct p54_common *priv,| struct sk_buff *skb)|{| struct p54_hdr *hdr = (struct p54_hdr *) skb->data;| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data;|| if (priv->fw_var >= 0x509) {| memcpy(priv->eeprom, eeprom->v2.data,| le16_to_cpu(eeprom->v2.len));| } else {| memcpy(priv->eeprom, eeprom->v1.data,| le16_to_cpu(eeprom->v1.len));| }| [...]The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom().The device is supposed to provide the same length back to the driver.But yes, it's possible (like shown in the report) to alter the valueto something that causes a crash/panic due to overrun.This patch addresses the issue by adding the size to the common devicecontext, so p54_rx_eeprom_readback no longer relies on possibly tamperedvalues... That said, it also checks if the "firmware" altered the valueand no longer copies them.The one, small saving grace is: Before the driver tries to read the eeprom,it needs to upload >a< firmware. the vendor firmware has a proprietarylicense and as a reason, it is not present on most distributions bydefault.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: NFSv4 file creation neglects setting ACLAn NFSv4 client that sets an ACL with a named principal during filecreation retrieves the ACL afterwards, and finds that it is only adefault ACL (based on the mode bits) and not the ACL that wasrequested during file creation. This violates RFC 8881 section6.4.1.3: "the ACL attribute is set as given".The issue occurs in nfsd_create_setattr(), which callsnfsd_attrs_valid() to determine whether to call nfsd_setattr().However, nfsd_attrs_valid() checks only for iattr changes andsecurity labels, but not POSIX ACLs. When only an ACL is present,the function returns false, nfsd_setattr() is skipped, and thePOSIX ACL is never applied to the inode.Subsequently, when the client retrieves the ACL, the server findsno POSIX ACL on the inode and returns one generated from the file'smode bits rather than returning the originally-specified ACL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: close race conditions on sk_receive_queuesk->sk_receive_queue is protected by skb queue lock, but for KCMsockets its RX path takes mux->rx_lock to protect more than justskb queue. However, kcm_recvmsg() still only grabs the skb queuelock, so race conditions still exist.We can teach kcm_recvmsg() to grab mux->rx_lock too but this wouldintroduce a potential performance regression as struct kcm_mux canbe shared by multiple KCM sockets.So we have to enforce skb queue lock in requeue_rx_msgs() and handleskb peek case carefully in kcm_wait_data(). Fortunately,skb_recv_datagram() already handles it nicely and is widely used byother sockets, we can just switch to skb_recv_datagram() aftergetting rid of the unnecessary sock lock in kcm_recvmsg() andkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,so it is safe to get rid of this check too.I ran the original syzbot reproducer for 30 min without seeing anyissue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.1).
-
Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:xsk: Fix race condition in AF_XDP generic RX pathMove rx_lock from xsk_socket to xsk_buff_pool.Fix synchronization for shared umem mode ingeneric RX path where multiple sockets sharesingle xsk_buff_pool.RX queue is exclusive to xsk_socket, while FILLqueue can be shared between multiple sockets.This could result in race condition where twoCPU cores access RX path of two different socketssharing the same umem.Protect both queues by acquiring spinlock in sharedxsk_buff_pool.Lock contention may be minimized in the future by someper-thread FQ buffering.It's safe and necessary to move spin_lock_bh(rx_lock)after xsk_rcv_check():* xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers.* xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix panic when forwarding a pkt with no in6 devkongweibin reported a kernel panic in ip6_forward() when input interfacehas no in6 dev associated.The following tc commands were used to reproduce this panic:tc qdisc del dev vxlan100 roottc qdisc add dev vxlan100 root netem corrupt 5%
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspaceCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes/dev/kvm to userspace and thus allows userspace to create VMs (and callother ioctls). E.g. KVM will encounter a NULL pointer when attempting toadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able tocreate a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: cti: Fix hang in cti_disable_hw()cti_enable_hw() and cti_disable_hw() are called from an atomic contextso shouldn't use runtime PM because it can result in a sleep whencommunicating with firmware.Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clockmanagement to the SCMI power domain""), this causes a hang on Juno whenrunning the Perf Coresight tests or running this command: perf record -e cs_etm//u -- lsThis was also missed until the revert commit because pm_runtime_put()was called with the wrong device until commit 692c9a499b28 ("coresight:cti: Correct the parameter for pm_runtime_put")With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174Fix the issue by removing the runtime PM calls completely. They are notneeded here because it must have already been done when building thepath for a trace.[ Fix build warnings ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash when I/O abort times outWhile performing CPU hotplug, a crash with the following stack was seen:Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0On abort timeout, completion was called without checking if the I/O wasalready completed.Verify that I/O and abort request are indeed outstanding before attemptingcompletion.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: alx: take rtnl_lock on resumeZbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0indeed the driver does not hold rtnl_lock during its internal closeand re-open functions during suspend/resume. Note that this is nota huge bug as the driver implements its own locking, and does notimplement changing the number of queues, but we need to silencethe splat.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failureIf creation or finalization of a checkpoint fails due to anomalies in thecheckpoint metadata on disk, a kernel warning is generated.This patch replaces the WARN_ONs by nilfs_error, so that a kernel, bootedwith panic_on_warn, does not panic. A nilfs_error is appropriate here tohandle the abnormal filesystem condition.This also replaces the detected error codes with an I/O error so thatneither of the internal error codes is returned to callers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: eeprom: fix null-deref on genl_info in dumpThe similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref ongenl_info in dump") is also needed for ethtool eeprom.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ensure sane device mtu in tunnelsAnother syzbot report [1] with no reproducer hintsat a bug in ip6_gre tunnel (dev:ip6gretap0)Since ipv6 mcast code makes sure to read dev->mtu onceand applies a sanity check on it (see commit b9b312a7a451"ipv6: mcast: better catch silly mtu values"), a remainingpossibility is that a layer is able to set dev->mtu toan underflowed value (high order bit set).This could happen indeed in ip6gre_tnl_link_config_route(),ip6_tnl_link_config() and ipip6_tunnel_bind_dev()Make sure to sanitize mtu value in a local variable beforeit is written once on dev->mtu, as lockless readers couldcatch wrong temporary value.[1]skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0------------[ cut here ]------------kernel BUG at net/core/skbuff.c:120Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022Workqueue: mld mld_ifc_workpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116sp : ffff800020dd3b60x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089Call trace:skb_panic+0x4c/0x50 net/core/skbuff.c:116skb_over_panic net/core/skbuff.c:125 [inline]skb_put+0xd4/0xdc net/core/skbuff.c:2049ip6_mc_hdr net/ipv6/mcast.c:1714 [inline]mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765add_grhead net/ipv6/mcast.c:1851 [inline]add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653process_one_work+0x2d8/0x504 kernel/workqueue.c:2289worker_thread+0x340/0x610 kernel/workqueue.c:2436kthread+0x12c/0x158 kernel/kthread.c:376ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/mem: Fix shutdown orderIra reports that removing cxl_mock_mem causes a crash with the followingtrace: BUG: kernel NULL pointer dereference, address: 0000000000000044 [..] RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core] [..] Call Trace: cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x29/0x40 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 device_unregister+0x13/0x60 devm_release_action+0x4d/0x90 ? __pfx_unregister_port+0x10/0x10 [cxl_core] delete_endpoint+0x121/0x130 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 ? lock_release+0x142/0x290 cdev_device_del+0x15/0x50 cxl_memdev_unregister+0x54/0x70 [cxl_core]This crash is due to the clearing out the cxl_memdev's driver context(@cxlds) before the subsystem is done with it. This is ultimately due tothe region(s), that this memdev is a member, being torn down and expectingto be able to de-reference @cxlds, like here:static int cxl_region_decode_reset(struct cxl_region *cxlr, int count)... if (cxlds->rcd) goto endpoint_reset;...Fix it by keeping the driver context valid until memdev-deviceunregistration, and subsequently the entire stack of relateddependencies, unwinds.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: allow ext4_get_group_info() to failPreviously, ext4_get_group_info() would treat an invalid group numberas BUG(), since in theory it should never happen. However, if amalicious attaker (or fuzzer) modifies the superblock via the blockdevice while it is the file system is mounted, it is possible fors_first_data_block to get set to a very large number. In that case,when calculating the block group of some block number (such as thestarting block of a preallocation region), could result in anunderflow and very large block group number. Then the BUG_ON check inext4_get_group_info() would fire, resutling in a denial of serviceattack that can be triggered by root or someone with write access tothe block device.For a quality of implementation perspective, it's best that even ifthe system administrator does something that they shouldn't, that itwill not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()will call ext4_error and return NULL. We also add fallback code inall of the callers of ext4_get_group_info() that it might NULL.Also, since ext4_get_group_info() was already borderline to be aninline function, un-inline it. The results in a next reduction of thecompiled text size of ext4 by roughly 2k.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-edRegistering a kprobe on __rcu_irq_enter_check_tick() can cause kernelstack overflow as shown below. This issue can be reproduced by enablingCONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",and then giving the following commands at the shell prompt: # cd /sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enableThis commit therefore adds __rcu_irq_enter_check_tick() to the kprobesblacklist using NOKPROBE_SYMBOL().Insufficient stack space to handle exception!ESR: 0x00000000f2000004 -- BRK (AArch64)FAR: 0x0000ffffccf3e510Task stack: [0xffff80000ad30000..0xffff80000ad38000]IRQ stack: [0xffff800008050000..0xffff800008058000]Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19Hardware name: linux,dummy-virt (DT)pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __rcu_irq_enter_check_tick+0x0/0x1b8lr : ct_nmi_enter+0x11c/0x138sp : ffff80000ad30080x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6cx14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000Kernel panic - not syncing: kernel stack overflowCPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc+0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194SMP: stopping secondary CPUsKernel Offset: 0x28da86000000 from 0xffff800008000000PHYS_OFFSET: 0xfffff76600000000CPU features: 0x00000,01a00100,0000421bMemory Limit: none
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix one memleak in __inet_del_ifa()I got the below warning when do fuzzing test:unregister_netdevice: waiting for bond0 to become free. Usage count = 2It can be repoduced via:ip link add bond0 type bondsysctl -w net.ipv4.conf.bond0.promote_secondaries=1ip addr add 4.117.174.103/0 scope 0x40 dev bond0ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0ip addr del 4.117.174.103/0 scope 0x40 dev bond0ip link delete bond0 type bondIn this reproduction test case, an incorrect 'last_prim' is found in__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)is lost. The memory of the secondary address is leaked and the reference ofin_device and net_device is leaked.Fix this problem:Look for 'last_prim' starting at location of the deleted IP and insertingthe promoted IP into the location of 'last_prim'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Lock external INTx masking opsMask operations through config space changes to DisINTx may race INTxconfiguration changes via ioctl. Create wrappers that add locking forpaths outside of the core interrupt code.In particular, irq_type is updated holding igate, therefore testingis_intx() requires holding igate. For example clearing DisINTx fromconfig space can otherwise race changes of the interrupt configuration.This aligns interfaces which may trigger the INTx eventfd into twocamps, one side serialized by igate and the other only enabled whileINTx is configured. A subsequent patch introduces synchronization forthe latter flows.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end ofa line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer atthe specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.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:bpf: Prevent tailcall infinite loop caused by freplaceThere is a potential infinite loop issue that can occur when using acombination of tail calls and freplace.In an upcoming selftest, the attach target for entry_freplace oftailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call inentry_freplace leads to entry_tc. This results in an infinite loop:entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.The problem arises because the tail_call_cnt in entry_freplace resets tozero each time entry_freplace is executed, causing the tail call mechanismto never terminate, eventually leading to a kernel panic.To fix this issue, the solution is twofold:1. Prevent updating a program extended by an freplace program to a prog_array map.2. Prevent extending a program that is already part of a prog_array map with an freplace program.This ensures that:* If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.* If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.Moreover, an extension program should not be tailcalled. As such, return-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to aprog_array map.Additionally, fix a minor code style issue by replacing eight spaces with atab for proper formatting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: unquiesce admin_q before destroy itKernel will hang on destroy admin_q while we create ctrl failed, suchas following calltrace:PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002bThis due to we have quiesced admi_q before cancel requests, but forgotto unquiesce before destroy it, as a result we fail to drain thepending requests, and hang on blk_mq_freeze_queue_wait() forever. Heretry to reuse nvme_rdma_teardown_admin_queue() to fix this issue andsimplify the code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: devmap: provide rxq after redirectrxq contains a pointer to the device from wherethe redirect happened. Currently, the BPF programthat was executed after a redirect via BPF_MAP_TYPE_DEVMAP*does not have it set.This is particularly bad since accessing ingress_ifindex, e.g.SEC("xdp")int prog(struct xdp_md *pkt){ return bpf_redirect_map(&dev_redirect_map, 0, 0);}SEC("xdp/devmap")int prog_after_redirect(struct xdp_md *pkt){ bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS;}depends on access to rxq, so a NULL pointer gets dereferenced:<1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000<1>[ 574.475188] #PF: supervisor read access in kernel mode<1>[ 574.475194] #PF: error_code(0x0000) - not-present page<6>[ 574.475199] PGD 0 P4D 0<4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23<4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023<4>[ 574.475231] Workqueue: mld mld_ifc_work<4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b<4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206<4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000<4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0<4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001<4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000<4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000<4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000<4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0<4>[ 574.475303] PKRU: 55555554<4>[ 574.475306] Call Trace:<4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70<4>[ 574.475329] ? page_fault_oops+0x180/0x4c0<4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490<4>[ 574.475346] ? kmem_cache_free+0x257/0x280<4>[ 574.475357] ? exc_page_fault+0x67/0x150<4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30<4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475386] bq_xmit_all+0x158/0x420<4>[ 574.475397] __dev_flush+0x30/0x90<4>[ 574.475407] veth_poll+0x216/0x250 [veth]<4>[ 574.475421] __napi_poll+0x28/0x1c0<4>[ 574.475430] net_rx_action+0x32d/0x3a0<4>[ 574.475441] handle_softirqs+0xcb/0x2c0<4>[ 574.475451] do_softirq+0x40/0x60<4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70<4>[ 574.475471] __dev_queue_xmit+0x268/0xe40<4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420<4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0<4>[ 574.475502] ip6_finish_output2+0x2be/0x640<4>[ 574.475512] ? nf_hook_slow+0x42/0xf0<4>[ 574.475521] ip6_finish_output+0x194/0x300<4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10<4>[ 574.475538] mld_sendpack+0x17c/0x240<4>[ 574.475548] mld_ifc_work+0x192/0x410<4>[ 574.475557] process_one_work+0x15d/0x380<4>[ 574.475566] worker_thread+0x29d/0x3a0<4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475587] kthread+0xcd/0x100<4>[ 574.475597] ? __pfx_kthread+0x10/0x10<4>[ 574.475606] ret_from_fork+0x31/0x50<4>[ 574.475615] ? __pfx_kthread+0x10/0x10<4>[ 574.475623] ret_from_fork_asm+0x1a/0x---truncated---
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ts2020: fix null-ptr-deref in ts2020_probe()KASAN reported a null-ptr-deref issue when executing the followingcommand: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...The cause of the problem is that when using sysfs to dynamically registeran i2c device, there is no platform data, but the probe process of ts2020needs to use platform data, resulting in a null pointer being accessed.Solve this problem by adding checks to platform data.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Create all dump files during debugfs initializationFor the current debugfs of hisi_sas, after user triggers dump, thedriver allocate memory space to save the register information and createdebugfs files to display the saved information. In this process, thedebugfs files created after each dump.Therefore, when the dump is triggered while the driver is unbind, thefollowing hang occurs:[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[67840.862947] Mem abort info:[67840.865855] ESR = 0x0000000096000004[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits[67840.875125] SET = 0, FnV = 0[67840.878291] EA = 0, S1PTW = 0[67840.881545] FSC = 0x04: level 0 translation fault[67840.886528] Data abort info:[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[67841.003628] pc : down_write+0x30/0x98[67841.007546] lr : start_creating.part.0+0x60/0x198[67841.012495] sp : ffff8000b979ba20[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0[67841.089759] Call trace:[67841.092456] down_write+0x30/0x98[67841.096017] start_creating.part.0+0x60/0x198[67841.100613] debugfs_create_dir+0x48/0x1f8[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw][67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw][67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw][67841.125115] full_proxy_write+0x68/0xc8[67841.129175] vfs_write+0xd8/0x3f0[67841.132708] ksys_write+0x70/0x108[67841.136317] __arm64_sys_write+0x24/0x38[67841.140440] invoke_syscall+0x50/0x128[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0[67841.149273] do_el0_svc+0x24/0x38[67841.152773] el0_svc+0x38/0xd8[67841.156009] el0t_64_sync_handler+0xc0/0xc8[67841.160361] el0t_64_sync+0x1a4/0x1a8[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)[67841.170443] ---[ end trace 0000000000000000 ]---To fix this issue, create all directories and files during debugfsinitialization. In this way, the driver only needs to allocate memoryspace to save information each time the user triggers dumping.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: avoid NULL pointer error during sdio removeWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdioworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ONis set to yes, kernel panic will happen:Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2cThis is because during 'rmmod ath10k', ath10k_sdio_remove() will callath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()will finally be called in ath10k_core_destroy(). This function will freestruct cfg80211_registered_device *rdev and all its members, includingwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdioworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.After device release, destroy_workqueue() will use NULL pointer then thekernel panic happen.Call trace:ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueueNeed to call destroy_workqueue() before ath10k_core_destroy(), freethe work queue buffer first and then free pointer of work queue byath10k_core_destroy(). This order matches the error path order inath10k_sdio_probe().No work will be queued on sdio workqueue between it is destroyed andath10k_core_destroy() is called. Based on the call_stack above, thereason is:Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() andath10k_sdio_irq_disable() will queue work on sdio workqueue.Sleep timer will be deleted before ath10k_core_destroy() inath10k_hif_power_down().ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().ath10k_core_unregister() will call ath10k_hif_power_down() to stop hifbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: independent PMD page table shared countThe folio refcount may be increased unexpectly through try_get_folio() bycaller such as split_huge_pages. In huge_pmd_unshare(), we use refcountto check whether a pmd page table is shared. The check is incorrect ifthe refcount is increased by the above caller, and this can cause the pagetable leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198The issue may be triggered by damon, offline_page, page_idle, etc, whichwill increase the refcount of page table.1. The page table itself will be discarded after reporting the "nonzero mapcount".2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.Fix it by introducing independent PMD page table shared count. Asdescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscvpmds, so we can reuse the field as pt_share_count.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla1280: Fix kernel oops when debug level > 2A null dereference or oops exception will eventually occur when qla1280.cdriver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. Ithink its clear from the code that the intention here is sg_dma_len(s) notlength of sg_next(s) when printing the debug info.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: decrease cached dst counters in dst_releaseUpstream fix ac888d58869b ("net: do not delay dst_entries_add() indst_release()") moved decrementing the dst count from dst_destroy todst_release to avoid accessing already freed data in case of netnsdismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnelsare used, this fix is incomplete as the same issue will be seen forcached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30Fix this by invalidating the cache, and thus decrementing cached dstcounters, in dst_release too.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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.5 (version in image is 15.5-150500.61.4.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:jfs: add sanity check for agwidth in dbMountThe width in dmapctl of the AG is zero, it trigger a divide error whencalculating the control page level in dbAllocAG.To avoid this issue, add a check for agwidth in dbAllocAG.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Add check for get_zeroed_page()Add check for the return value of get_zeroed_page() insclp_console_init() to prevent null pointer dereference.Furthermore, to solve the memory leak caused by the loopallocation, add a free helper to do the free job.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix oob write in trace_seq_to_buffer()syzbot reported this bug:==================================================================BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 ....==================================================================It has been reported that trace_seq_to_buffer() tries to copy more datathan PAGE_SIZE to buf. Therefore, to prevent this, we should use thesmaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihidThere is a string parsing logic error which can lead to an overflow of hidor uid buffers. Comparing ACPIID_LEN against a total string length doesn'ttake into account the lengths of individual hid and uid buffers so thecheck is insufficient in some cases. For example if the length of hidstring is 4 and the length of the uid string is 260, the length of strwill be equal to ACPIID_LEN + 1 but uid string will overflow uid bufferwhich size is 256.The same applies to the hid string with length 13 and uid string withlength 250.Check the length of hid and uid strings separately to preventbuffer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix NULL pointer accessThis patch ensures that the UCSI driver waits for all pending tasks in theucsi_displayport_work workqueue to finish executing before proceeding withthe partner removal.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: correct the order of prelim_ref arguments in btrfs__prelim_refbtrfs_prelim_ref() calls the old and new reference variables in theincorrect order. This causes a NULL pointer dereference because oldrefis passed as NULL to trace_btrfs_prelim_ref_insert().Note, trace_btrfs_prelim_ref_insert() is being called with newref asoldref (and oldref as NULL) on purpose in order to print outthe values of newref.To reproduce:echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enablePerform some writeback operations.Backtrace:BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chnThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss canrun on multiple platforms having different DMA architectures.On some platforms there can be one FDQ for all flows in the RX channelwhile for others there is a separate FDQ for each flow in the RX channel.So far we have been relying on the skip_fdq argument ofk3_udma_glue_reset_rx_chn().Instead of relying on the user to provide this information, infer itbased on DMA architecture during k3_udma_glue_request_rx_chn() and save itin an internal flag 'single_fdq'. Use that flag atk3_udma_glue_reset_rx_chn() to deicide if the FDQ needsto be cleared for every flow or just for flow 0.Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.> ip link set eth1 down> ip link set eth0 down> ethtool -L eth0 rx 8> ip link set eth0 up> modprobe -r ti_am65_cpsw_nuss[ 103.045726] ------------[ cut here ]------------[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcasp drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 rfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool][ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.154709] sp : ffff8000826ebbc0[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000[ 103.229274] Call trace:[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss][ 103.244942] devm_action_release+0x14/0x20[ 103.249040] release_nodes+0x3c/0x68[ 103.252610] devres_release_all+0x8c/0xdc[ 103.256614] device_unbind_cleanup+0x18/0x60[ 103.260876] device_release_driver_internal+0xf8/0x178[ 103.266004] driver_detach+0x50/0x9c[ 103.269571] bus_remove_driver+0x6c/0xbc[ 103.273485] driver_unregister+0x30/0x60[ 103.277401] platform_driver_unregister+0x14/0x20[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss][ 103.288620] __arm64_sys_delete_module+0x17c/0x25c[ 103.293404] invoke_syscall+0x44/0x100[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0[ 103.301845] do_el0_svc+0x1c/0x28[ 103.305155] el0_svc+0x28/0x98---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix unconditional IO throttle caused by REQ_PREFLUSHWhen a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,which causes the flush_bio to be throttled by wbt_wait().An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"),the metadata submitted by xlog_write_iclog() should not be throttled.But due to the existence of the dm layer, throttling flush_bio indirectlycauses the metadata bio to be throttled.Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makeswbt_should_throttle() return false to avoid wbt_wait().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/iopl: Cure TIF_IO_BITMAP inconsistenciesio_bitmap_exit() is invoked from exit_thread() when a task exists orwhen a fork fails. In the latter case the exit_thread() cleans upresources which were allocated during fork().io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends upin tss_update_io_bitmap(). tss_update_io_bitmap() operates on thecurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,tss_update_io_bitmap() crashes with a NULL pointer dereference.There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap().Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().For paranoia sake, add a warning into tss_update_io_bitmap() to catchthe case, when that code is invoked with inconsistent state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: Fix potential null-ptr-deref in mlb_usio_probe()devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()does not check for this case, which could result in a NULL pointerdereference.Add NULL check after devm_ioremap() to prevent this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Clear table_sz when rproc_shutdownThere is case as below could trigger kernel dump:Use U-Boot to start remote processor(rproc) with resource tablepublished to a fixed address by rproc. After Kernel boots up,stop the rproc, load a new firmware which doesn't have resource table,and start rproc.When starting rproc with a firmware not have resource table,`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` willtrigger dump, because rproc->cache_table is set to NULL during the laststop operation, but rproc->table_sz is still valid.This issue is found on i.MX8MP and i.MX9.Dump as below:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000[0000000000000000] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] PREEMPT SMPModules linked in:CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38Hardware name: NXP i.MX8MPlus EVK board (DT)pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __pi_memcpy_generic+0x110/0x22clr : rproc_start+0x88/0x1e0Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19cClear rproc->table_sz to address the issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================Even though fbcon_init() checks beforehand if fb_match_mode() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cxusb: no longer judge rbuf when the write failssyzbot reported a uninit-value in cxusb_i2c_xfer. [1]Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()will be executed to read rlen bytes of data from the dvb device into therbuf.In this case, although rlen is 1, the write operation failed which resultedin the dvb read operation not being executed, and ultimately variable i wasnot initialized.[1]BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It'sthen passed to fb_cvt_hperiod(), where it's used as a divider -- divisionby 0 will result in kernel oops. Add a sanity check for cvt.f_refresh toavoid such overflow...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Log an error when close_all_cached_dirs failsUnder low-memory conditions, close_all_cached_dirs() can't move thedentries to a separate list to dput() them once the locks are dropped.This will result in a "Dentry still in use" error, so add an errormessage that makes it clear this is what happened:[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries[ 495.281595] ------------[ cut here ]------------[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs][ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0Also, bail out of looping through all tcons as soon as a singleallocation fails, since we're already in trouble, and kmalloc() attemptsfor subseqeuent tcons are likely to fail just like the first one did.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:software node: Correct a OOB check in software_node_get_reference_args()software_node_get_reference_args() wants to get @index-th element, sothe property value requires at least '(index + 1) * sizeof(*ref)' bytesbut that can not be guaranteed by current OOB check, and may cause OOBfor malformed property.Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi operand cache leak in dswstate.cACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732I found an ACPI cache leak in ACPI early termination and boot continuing case.When early termination occurs due to malicious ACPI table, Linux kernelterminates ACPI function and continues to boot process. While kernel terminatesACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.Boot log of ACPI operand cache leak is as follows:>[ 0.585957] ACPI: Added _OSI(Module Device)>[ 0.587218] ACPI: Added _OSI(Processor Device)>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)>[ 0.597858] ACPI: Unable to start the ACPI Interpreter>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26>[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006>[ 0.609177] Call Trace:>[ 0.610063] ? dump_stack+0x5c/0x81>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b>[ 0.619293] ? acpi_terminate+0xa/0x14>[ 0.620394] ? acpi_init+0x2af/0x34f>[ 0.621616] ? __class_create+0x4c/0x80>[ 0.623412] ? video_setup+0x7f/0x7f>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27>[ 0.625861] ? do_one_initcall+0x4e/0x1a0>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f>[ 0.628972] ? rest_init+0x80/0x80>[ 0.630043] ? kernel_init+0xa/0x100>[ 0.631084] ? ret_from_fork+0x25/0x30>[ 0.633343] vgaarb: loaded>[ 0.635036] EDAC MC: Ver: 3.0.0>[ 0.638601] PCI: Probing PCI hardware>[ 0.639833] PCI host bridge to bus 0000:00>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]> ... Continue to boot and log is omitted ...I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()function uses walk_state->operand_index for start position of the top, butacpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.Therefore, this causes acpi operand memory leak.This cache leak causes a security threat because an old kernel (<= 4.9) showsmemory locations of kernel functions in stack dump. Some malicious userscould use this information to neutralize kernel ASLR.I made a patch to fix ACPI operand cache leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.syzbot reported a warning below [1] following a fault injection innfs_fs_proc_net_init(). [0]When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warningis logged as the directory is not empty.Let's handle the error of nfs_fs_proc_net_init() properly.[0]:FAULT_INJECTION: forcing a failure.name failslab, interval 1, probability 0, space 0, times 0CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl (lib/dump_stack.c:123) should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174) should_failslab (mm/failslab.c:46) kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204) __proc_create (fs/proc/generic.c:427) proc_create_reg (fs/proc/generic.c:554) proc_create_net_data (fs/proc/proc_net.c:120) nfs_fs_proc_net_init (fs/nfs/client.c:1409) nfs_net_init (fs/nfs/inode.c:2600) ops_init (net/core/net_namespace.c:138) setup_net (net/core/net_namespace.c:443) copy_net_ns (net/core/net_namespace.c:576) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4)) ksys_unshare (kernel/fork.c:3123) __x64_sys_unshare (kernel/fork.c:3190) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [1]:remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs' WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727Modules linked in:CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00RSP: 0018:ffffc90003637b08 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76 ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253 setup_net+0x2e1/0x510 net/core/net_namespace.c:457 copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574 create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksys_unshare+0x45b/0xa40 kernel/fork.c:3121 __do_sys_unshare kernel/fork.c:3192 [inline] __se_sys_unshare kernel/fork.c:3190 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa1a6b8e929Code: 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 c---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/s390: Make attach succeed when the device was surprise removedWhen a PCI device is removed with surprise hotplug, there may still beattempts to attach the device to the default domain as part of tear downvia (__iommu_release_dma_ownership()), or because the removal happensduring probe (__iommu_probe_device()). In both cases zpci_register_ioat()fails with a cc value indicating that the device handle is invalid. Thisis because the device is no longer part of the instance as far as thehypervisor is concerned.Currently this leads to an error return and s390_iommu_attach_device()fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()because attaching to the default domain must never fail.With the device fenced by the hypervisor no DMAs to or from memory arepossible and the IOMMU translations have no effect. Proceed as if theregistration was successful and let the hotplug event handling clean upthe device.This is similar to how devices in the error state are handled sincecommit 59bbf596791b ("iommu/s390: Make attach succeed even if the deviceis in error state") except that for removal the domain will not beregistered later. This approach was also previously discussed at thelink.Handle both cases, error state and removal, in a helper which checks ifthe error needs to be propagated or ignored. Avoid magic numbercondition codes by using the pre-existing, but never used, defines forPCI load/store condition codes and rename them to reflect that theyapply to all PCI instructions.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: validate skb length for unknown CC opcodeIn hci_cmd_complete_evt(), if the command complete event has an unknownopcode, we assume the first byte of the remaining skb->data contains thereturn status. However, parameter data has previously been pulled inhci_event_func(), which may leave the skb empty. If so, using skb->data[0]for the return status uses un-init memory.The fix is to check skb->len before using skb->data.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check NULL before accessing[WHAT]IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomicfails with NULL pointer dereference. This can be reproduced withboth an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ...(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flagsWhen a filesystem is being automounted, it needs to preserve theuser-set superblock mount options, such as the "ro" flag.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libsodium23 > 0-0 (version in image is 1.0.18-150000.4.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Rubygems.org is the Ruby community's gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).
-
Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_netlink: Fix shift out of bounds in group mask calculationWhen a netlink message is received, netlink_recvmsg() fills in the addressof the sender. One of the fields is the 32-bit bitfield nl_groups, whichcarries the multicast group on which the message was received. The leastsignificant bit corresponds to group 1, and therefore the highest groupthat the field can represent is 32. Above that, the UB sanitizer flags theout-of-bounds shift attempts.Which bits end up being set in such case is implementation defined, butit's either going to be a wrong non-zero value, or zero, which is at leastnot misleading. Make the latter choice deterministic by always setting to 0for higher-numbered multicast groups.To get information about membership in groups >= 32, userspace is expectedto use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFOsocket option.[0] https://lwn.net/Articles/147608/The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridgeWhich produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powercap: intel_rapl: fix UBSAN shift-out-of-bounds issueWhen value < time_unit, the parameter of ilog2() will be zero andthe return value is -1. u64(-1) is too large for shift exponentand then will trigger shift-out-of-bounds:shift exponent 18446744073709551615 is too large for 32-bit type 'int'Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXLWindow X". This confuses region_intersects(), which expects all "SystemRAM" resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be "Operation not permitted" instead of "Bad address". Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn't allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, "System RAM" is a descendant of "CXL Window 0" instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with "System RAM" not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- "CXL Window 0" ------------||-- "System RAM" --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- "System RAM" --||-- "CXL Window 0a" --|Where "CXL Window 0a" is part of the original "CXL Window 0" thatisn't covered by "System RAM".
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate l_tree_depth to avoid out-of-bounds accessThe l_tree_depth field is 16-bit (__le16), but the actual maximum depth islimited to OCFS2_MAX_PATH_DEPTH.Add a check to prevent out-of-bounds access if l_tree_depth has an invalidvalue, which may occur when reading from a corrupted mounted disk [1].
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.1).
-
Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:x86/mce: Work around an erratum on fast string copy instructionsA rare kernel panic scenario can happen when the following conditionsare met due to an erratum on fast string copy instructions:1) An uncorrected error.2) That error must be in first cache line of a page.3) Kernel must execute page_copy from the page immediately before thatpage.The fast string copy instructions ("REP; MOVS*") could consume anuncorrectable memory error in the cache line _right after_ the desiredregion to copy and raise an MCE.Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast stringcopy and will avoid such spurious machine checks. However, that is lesspreferable due to the permanent performance impact. Considering memorypoison is rare, it's desirable to keep fast string copy enabled until anMCE is seen.Intel has confirmed the following:1. The CPU erratum of fast string copy only applies to Skylake,Cascade Lake and Cooper Lake generations.Directly return from the MCE handler:2. Will result in complete execution of the "REP; MOVS*" with no dataloss or corruption.3. Will not result in another MCE firing on the next poisoned cache linedue to "REP; MOVS*".4. Will resume execution from a correct point in code.5. Will result in the same instruction that triggered the MCE firing asecond MCE immediately for any other software recoverable data fetcherrors.6. Is not safe without disabling the fast string copy, as the next faststring copy of the same buffer on the same CPU would result in a PANICMCE.This should mitigate the erratum completely with the only caveat thatthe fast string copy is disabled on the affected hyper thread thusperformance degradation.This is still better than the OS crashing on MCEs raised on anirrelevant process due to "REP; MOVS*' accesses in a kernel context,e.g., copy_page.Injected errors on 1st cache line of 8 anonymous pages of process'proc1' and observed MCE consumption from 'proc2' with no panic(directly returned).Without the fix, the host panicked within a few minutes on arandom 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: implement ->free_diskEnsure that the lo_device which is stored in the gendisk privatedata is valid until the gendisk is freed. Currently the loop driveruses a lot of effort to make sure a device is not freed when it isstill in use, but to to fix a potential deadlock this will be relaxeda bit soon.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tunnel: wait until all sk_user_data reader finish before releasing the sockThere is a race condition in vxlan that when deleting a vxlan deviceduring receiving packets, there is a possibility that the sock isreleased after getting vxlan_sock vs from sk_user_data. Then inlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will gotNULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.shFix this by waiting for all sk_user_data reader to finish beforereleasing the sock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: ftrace: fix module PLTs with mcountLi Huafei reports that mcount-based ftrace with module PLTs was brokenby commit: a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.")When a module PLTs are used and a module is loaded sufficiently far awayfrom the kernel, we'll create PLTs for any branches which areout-of-range. These are separate from the special ftrace trampolinePLTs, which the module PLT code doesn't directly manipulate.When mcount is in use this is a problem, as each mcount callsite in amodule will be initialized to point to a module PLT, but since commita6253579977e4c6f ftrace_make_nop() will assume that the callsite hasbeen initialized to point to the special ftrace trampoline PLT, andftrace_find_callable_addr() rejects other cases.This means that when ftrace tries to initialize a callsite viaftrace_make_nop(), the call to ftrace_find_callable_addr() will findthat the `_mcount` stub is out-of-range and is not handled by the ftracePLT, resulting in a splat:| ftrace_test: loading out-of-tree module taints kernel.| ftrace: no module PLT for _mcount| ------------[ ftrace bug ]------------| ftrace failed to modify| [] 0xffff800029180014| actual: 44:00:00:94| Initializing ftrace call sites| ftrace record flags: 2000000| (0)| expected tramp: ffff80000802eb3c| ------------[ cut here ]------------| WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270| Modules linked in:| CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22| Hardware name: linux,dummy-virt (DT)| pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : ftrace_bug+0x94/0x270| lr : ftrace_bug+0x21c/0x270| sp : ffff80000b2bbaf0| x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000| x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00| x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8| x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff| x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118| x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666| x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030| x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4| x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001| x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022| Call trace:| ftrace_bug+0x94/0x270| ftrace_process_locs+0x308/0x430| ftrace_module_init+0x44/0x60| load_module+0x15b4/0x1ce8| __do_sys_init_module+0x1ec/0x238| __arm64_sys_init_module+0x24/0x30| invoke_syscall+0x54/0x118| el0_svc_common.constprop.4+0x84/0x100| do_el0_svc+0x3c/0xd0| el0_svc+0x1c/0x50| el0t_64_sync_handler+0x90/0xb8| el0t_64_sync+0x15c/0x160| ---[ end trace 0000000000000000 ]---| ---------test_init-----------Fix this by reverting to the old behaviour of ignoring the oldinstruction when initialising an mcount callsite in a module, which wasthe behaviour prior to commit a6253579977e4c6f.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesA bogus device can provide a bNumConfigurations value that exceeds theinitial value used in usb_get_configuration for allocating dev->config.This can lead to out-of-bounds accesses later, e.g. inusb_destroy_configuration.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix the infinite loop in exfat_readdir()If the file system is corrupted so that a cluster is linked toitself in the cluster chain, and there is an unused directoryentry in the cluster, 'dentry' will not be incremented, causingcondition 'dentry < max_dentries' unable to prevent an infiniteloop.This infinite loop causes s_lock not to be released, and othertasks will hang, such as exfat_sync_fs().This commit stops traversing the cluster chain when there is unuseddirectory entry in the cluster to avoid this infinite loop.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer dereference in l3mdev_l3_rcvWhen delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3sThis may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354This is because l3mdev_l3_rcv() visit dev->l3mdev_ops afteripvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The processlike this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops |To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid journaling sb update on error if journal is destroyingPresently we always BUG_ON if trying to start a transaction on a journal markedwith JBD2_UNMOUNT, since this should never happen. However, while ltp runningstress tests, it was observed that in case of some error handling paths, it ispossible for update_super_work to start a transaction after the journal isdestroyed eg:(umount)ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT)Hence, introduce a new mount flag to indicate journal is destroying and only doa journaled (and deferred) update of sb if this flag is not set. Otherwise, justfallback to an un-journaled commit.Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updatesThis sequence is important as it ensures that, after this point, there is no sbupdate that might be journaled so it is safe to update the sb outside thejournal. (To avoid race discussed in 2d01ddc86606)Also, we don't need a similar check in ext4_grp_locked_error since it is onlycalled from mballoc and AFAICT it would be always valid to schedule work here.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Fix deadlock when using NCM gadgetThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").Under PREEMPT_RT the deadlock can be readily triggered by heavy networktraffic, for example using "iperf --bidir" over NCM ethernet link.The deadlock occurs because the threaded interrupt handler getspreempted by a softirq, but both are protected by the same spinlock.Prevent deadlock by disabling softirq during threaded irq handler.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: mctrl_gpio: split disable_ms into sync and no_sync APIsThe following splat has been observed on a SAMA5D27 platform usingatmel_serial:BUG: sleeping function called from invalid context at kernel/irq/manage.c:738in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0preempt_count: 1, expected: 0INFO: lockdep is turned off.irq event stamp: 0hardirqs last enabled at (0): [<00000000>] 0x0hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7becsoftirqs last enabled at (0): [] copy_process+0x1ca0/0x7becsoftirqs last disabled at (0): [<00000000>] 0x0CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74Hardware name: Atmel SAMA5Workqueue: hci0 hci_power_on [bluetooth]Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28This warning is emitted when trying to toggle, at the highest level,some flow control (with serdev_device_set_flow_control) in a devicedriver. At the lowest level, the atmel_serial driver is usingserial_mctrl_gpio lib to enable/disable the corresponding IRQsaccordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due todisable_irq (called in mctrl_gpio_disable_ms) being possibly called insome atomic context (some tty drivers perform modem lines configurationin regions protected by port lock).Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking oneand a blocking one. Replace mctrl_gpio_disable_ms calls with therelevant version depending on whether the call is protected by some portlock.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: prevent BUG_ON by blocking retries on failed device resumesA cache device failing to resume due to mapping errors should not beretried, as the failure leaves a partially initialized policy object.Repeating the resume operation risks triggering BUG_ON when reloadingcache mappings into the incomplete policy object.Reproduce steps:1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.cat <> cmeta.xml EOFdmsetup create cmeta --table "0 8192 linear /dev/sdc 0"cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2dmsetup remove cmeta2. wipe the second array block of the mapping array to simulate data degradations.mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try bringing up the cache device. The resume is expected to fail due to the broken array block.dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dmsetup create cache --notabledmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup resume cache4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.dmsetup resume cacheKernel logs:(snip)------------[ cut here ]------------kernel BUG at drivers/md/dm-cache-policy-smq.c:752!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3RIP: 0010:smq_load_mapping+0x3e5/0x570Fix by disallowing resume operations for devices that failed theinitial attempt.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix race between nfsd registration and exports_procAs of now nfsd calls create_proc_exports_entry() at start of init_nfsdand cleanup by remove_proc_entry() at last of exit_nfsd.Which causes kernel OOPs if there is race between below 2 operations:(i) exportfs -r(ii) mount -t nfsd none /proc/fs/nfsdfor 5.4 kernel ARM64:CPU 1:el1_irq+0xbc/0x180arch_counter_get_cntvct+0x14/0x18running_clock+0xc/0x18preempt_count_add+0x88/0x110prep_new_page+0xb0/0x220get_page_from_freelist+0x2d8/0x1778__alloc_pages_nodemask+0x15c/0xef0__vmalloc_node_range+0x28c/0x478__vmalloc_node_flags_caller+0x8c/0xb0kvmalloc_node+0x88/0xe0nfsd_init_net+0x6c/0x108 [nfsd]ops_init+0x44/0x170register_pernet_operations+0x114/0x270register_pernet_subsys+0x34/0x50init_nfsd+0xa8/0x718 [nfsd]do_one_initcall+0x54/0x2e0CPU 2 :Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010PC is at : exports_net_open+0x50/0x68 [nfsd]Call trace:exports_net_open+0x50/0x68 [nfsd]exports_proc_open+0x2c/0x38 [nfsd]proc_reg_open+0xb8/0x198do_dentry_open+0x1c4/0x418vfs_open+0x38/0x48path_openat+0x28c/0xf18do_filp_open+0x70/0xe8do_sys_open+0x154/0x248Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().and same is happening on latest 6.14 kernel as well:[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty...[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48...[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4...[ 285.469695] Call trace:[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)[ 285.470488] seq_read+0xe0/0x11c[ 285.470675] proc_reg_read+0x9c/0xf0[ 285.470874] vfs_read+0xc4/0x2fc[ 285.471057] ksys_read+0x6c/0xf4[ 285.471231] __arm64_sys_read+0x1c/0x28[ 285.471428] invoke_syscall+0x44/0x100[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0[ 285.471870] do_el0_svc_compat+0x1c/0x34[ 285.472073] el0_svc_compat+0x2c/0x80[ 285.472265] el0t_32_sync_handler+0x90/0x140[ 285.472473] el0t_32_sync+0x19c/0x1a0[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)[ 285.473422] ---[ end trace 0000000000000000 ]---It reproduced simply with below script:while [ 1 ]do/exportfs -rdone &while [ 1 ]doinsmod /nfsd.komount -t nfsd none /proc/fs/nfsdumount /proc/fs/nfsdrmmod nfsddone &So exporting interfaces to user space shall be done at last andcleanup at first place.With change there is no Kernel OOPs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,running at UDMA/33.The issue can be reproduced by running the same command with a cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0and sctp_ulpevent_make_authkey() returns 0, then the variableai_ev remains zero and the zero will be dereferencedin the sctp_ulpevent_free() function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:bpf: Fix invalid prog->stats access when update_effective_progs failsSyzkaller triggers an invalid memory access issue following faultinjection in update_effective_progs. The issue can be described asfollows:__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog---softirq start---__do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp)---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype])The reason is that fault injection caused update_effective_progs to failand then changed the original prog into dummy_bpf_prog.prog inpurge_effective_progs. Then a softirq came, and accessing the members ofdummy_bpf_prog.prog in the softirq triggers invalid mem access.To fix it, skip updating stats when stats is NULL.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix race condition in TTY wakeupA race condition occurs when gs_start_io() calls either gs_start_rx() orgs_start_tx(), as those functions briefly drop the port_lock forusb_ep_queue(). This allows gs_close() and gserial_disconnect() to clearport.tty and port_usb, respectively.Use the null-safe TTY Port helper function to wake up TTY.Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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.5 (version in image is 15.5-150500.61.4.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).
-
Description: Unknown.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).
-
Description: A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.
Packages affected:
- sle-module-basesystem-release == 15.5 (version in image is 15.5-150500.43.2).
- grub2 > 0-0 (version in image is 2.06-150500.29.56.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntb_netdev: Use dev_kfree_skb_any() in interrupt contextTX/RX callback handlers (ntb_netdev_tx_handler(),ntb_netdev_rx_handler()) can be called in interruptcontext via the DMA framework when the respectiveDMA operations have completed. As such, any callsby these routines to free skb's, should use theinterrupt context safe dev_kfree_skb_any() function.Previously, these callback handlers would call theinterrupt unsafe version of dev_kfree_skb(). This hasnot presented an issue on Intel IOAT DMA engines asthat driver utilizes tasklets rather than a hardinterrupt handler, like the AMD PTDMA DMA driver.On AMD systems, a kernel WARNING message isencountered, which is being issued fromskb_release_head_state() due to in_hardirq()being true.Besides the user visible WARNING from the kernel,the other symptom of this bug was that TCP/IP performanceacross the ntb_netdev interface was very poor, i.e.approximately an order of magnitude below what wasexpected. With the repair to use dev_kfree_skb_any(),kernel WARNINGs from skb_release_head_state() ceasedand TCP/IP performance, as measured by iperf, was onpar with expected results, approximately 20 Gb/s onAMD Milan based server. Note that this performanceis comparable with Intel based servers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was found in OpenSSL's handling of the properties argument in certain functions. This vulnerability can allow use-after-free exploitation, which may result in undefined behavior or incorrect property parsing, leading to OpenSSL treating the input as an empty string.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311-cryptography > 0-0 (version in image is 41.0.3-150400.16.22.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rseq: Fix segfault on registration when rseq_cs is non-zeroThe rseq_cs field is documented as being set to 0 by user-space prior toregistration, however this is not currently enforced by the kernel. Thiscan result in a segfault on return to user-space if the value stored inthe rseq_cs field doesn't point to a valid struct rseq_cs.The correct solution to this would be to fail the rseq registration whenthe rseq_cs field is non-zero. However, some older versions of glibcwill reuse the rseq area of previous threads without clearing therseq_cs field and will also terminate the process if the rseqregistration fails in a secondary thread. This wasn't caught in testingbecause in this case the leftover rseq_cs does point to a valid structrseq_cs.What we can do is clear the rseq_cs field on registration when it'snon-zero which will prevent segfaults on registration and won't breakthe glibc versions that reuse rseq areas on thread creation.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs().KCSAN found a data race in sock_recv_cmsgs() where the read accessto sk->sk_stamp needs READ_ONCE().BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsgwrite (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0: sock_write_timestamp include/net/sock.h:2670 [inline] sock_recv_cmsgs include/net/sock.h:2722 [inline] packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1: sock_recv_cmsgs include/net/sock.h:2721 [inline] packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0xffffffffc4653600 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()If device_register() fails in tcm_loop_setup_hba_bus(), the name allocatedby dev_set_name() need be freed. As comment of device_register() says, itshould use put_device() to give up the reference in the error path. So fixthis by calling put_device(), then the name can be freed in kobject_cleanup().The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't needgoto error label in this case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix multishot accept request leaksHaving REQ_F_POLLED set doesn't guarantee that the request isexecuted as a multishot from the polling path. Fortunately for us, ifthe code thinks it's multishot issue when it's not, it can only ask toskip completion so leaking the request. Use issue_flags to markmultipoll issues.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mhi: Fix memory leak in mhi_net_dellink()MHI driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch calls free_netdev() to fix it since netdev_privis used after unregister.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: fix fence ref countingWe leaked dependency fences when processes were beeing killed.Additional to that grab a reference to the last scheduled fence.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), forcrafted filesystem image can contain bogus length. There conditions arenot kernel bugs that can justify kernel to panic.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only decrement add_addr_accepted for MPJ reqAdding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)... before decrementing the add_addr_accepted counter helped to find abug when running the "remove single subflow" subtest from themptcp_join.sh selftest.Removing a 'subflow' endpoint will first trigger a RM_ADDR, then thesubflow closure. Before this patch, and upon the reception of theRM_ADDR, the other peer will then try to decrement thisadd_addr_accepted. That's not correct because the attached subflows havenot been created upon the reception of an ADD_ADDR.A way to solve that is to decrement the counter only if the attachedsubflow was an MP_JOIN to a remote id that was not 0, and initiated bythe host receiving the RM_ADDR.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only mark 'subflow' endp as availableAdding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0)... before decrementing the local_addr_used counter helped to find a bugwhen running the "remove single address" subtest from the mptcp_join.shselftests.Removing a 'signal' endpoint will trigger the removal of all subflowslinked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() withrm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_usedcounter, which is wrong in this case because this counter is linked to'subflow' endpoints, and here it is a 'signal' endpoint that is beingremoved.Now, the counter is decremented, only if the ID is being used outsideof mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, andif the ID is not 0 -- local_addr_used is not taking into account theseones. This marking of the ID as being available, and the decrement isdone no matter if a subflow using this ID is currently available,because the subflow could have been closed before.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/firmware: use dma non-coherent allocatorCurrently, enabling SG_DEBUG in the kernel will cause nouveau to hit aBUG() on startup, when the iommu is enabled:kernel BUG at include/linux/scatterlist.h:187!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019RIP: 0010:sg_init_one+0x85/0xa0Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 5424 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002bRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0Call Trace: ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? do_error_trap+0x65/0x80 ? sg_init_one+0x85/0xa0 ? exc_invalid_op+0x50/0x70 ? sg_init_one+0x85/0xa0 ? asm_exc_invalid_op+0x1a/0x20 ? sg_init_one+0x85/0xa0 nvkm_firmware_ctor+0x14a/0x250 [nouveau] nvkm_falcon_fw_ctor+0x42/0x70 [nouveau] ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau] r535_gsp_oneinit+0xb3/0x15f0 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? nvkm_udevice_new+0x95/0x140 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? ktime_get+0x47/0xb0Fix this by using the non-coherent allocator instead, I think theremight be a better answer to this, but it involve ripping up some ofAPIs using sg lists.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if we need to reschedule during overflow flushIn terms of normal application usage, this list will always be empty.And if an application does overflow a bit, it'll have a few entries.However, nothing obviously prevents syzbot from running a test casethat generates a ton of overflow entries, and then flushing them cantake quite a while.Check for needing to reschedule while flushing, and drop our locks anddo so if necessary. There's no state to maintain here as overflowsalways prune from head-of-list, hence it's fine to drop and reacquirethe locks at the end of the loop.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Get rid of userspace_irqchip_in_useImproper use of userspace_irqchip_in_use led to syzbot hitting thefollowing WARN_ON() in kvm_timer_update_irq():WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459kvm_timer_update_irq+0x21c/0x394Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret);Theoretically, since userspace_irqchip_in_use's functionality can besimply replaced by '!irqchip_in_kernel()', get rid of the static keyto avoid the mismanagement, which also helps with the syzbot issue.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: Fix the issue of resource not being properly released in xenbus_dev_probe()This patch fixes an issue in the function xenbus_dev_probe(). In thexenbus_dev_probe() function, within the if (err) branch at line 313, theprogram incorrectly returns err directly without releasing the resourcesallocated by err = drv->probe(dev, id). As the return value is non-zero,the upper layers assume the processing logic has failed. However, the probeoperation was performed earlier without a corresponding remove operation.Since the probe actually allocates resources, failing to perform the removeoperation could lead to problems.To fix this issue, we followed the resource release logic of thexenbus_dev_remove() function by adding a new block fail_remove before thefail_put block. After entering the branch if (err) at line 313, thefunction will use a goto statement to jump to the fail_remove block,ensuring that the previously acquired resources are correctly released,thus preventing the reference count leak.This bug was identified by an experimental static analysis tool developedby our team. The tool specializes in analyzing reference count operationsand detecting potential issues where resources are not properly managed.In this case, the tool flagged the missing release operation as apotential problem, which led to the development of this patch.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: release nexthop on device removalThe CI is hitting some aperiodic hangup at device removal time in thepmtu.sh self-test:unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0While the first suspect is the dst_cache, explicitly tracking the dstowing the last device reference via probes proved such dst is held bythe nexthop in the originating fib6_info.Similar to commit f5b51fe804ec ("ipv6: route: purge exception onremoval"), we need to explicitly release the originating fib info whendisconnecting a to-be-removed device from a live ipv6 dst: move thefib6_info cleanup into ip6_dst_ifdown().Tested running:./pmtu.sh cleanup_ipv6_exceptionin a tight loop for more than 400 iterations with no spat, running anunpatched kernel I observed a splat every ~10 iterations.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: kmx61: fix information leak in triggered bufferThe 'buffer' local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: vcnl4035: fix information leak in triggered bufferThe 'buffer' local array is used to push data to userspace from atriggered buffer, but it does not set an initial value for the singledata element, which is an u16 aligned to 8 bytes. That leaves at least4 bytes uninitialized even after writing an integer value withregmap_read().Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: pressure: zpa2326: fix information leak in triggered bufferThe 'sample' local struct is used to push data to user space from atriggered buffer, but it has a hole between the temperature and thetimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).This hole is never initialized.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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.5 (version in image is 15.5-150500.61.4.1).
- elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix memory leak in aRFS after resetFix aRFS (accelerated Receive Flow Steering) structures memory leak byadding a checker to verify if aRFS memory is already allocated whileconfiguring VSI. aRFS objects are allocated in two cases:- as part of VSI initialization (at probe), and- as part of reset handlingHowever, VSI reconfiguration executed during reset involves memoryallocation one more time, without prior releasing already allocatedresources. This led to the memory leak with the following signature:[root@os-delivery ~]# cat /sys/kernel/debug/kmemleakunreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [] __kmalloc_cache_noprof+0x275/0x340 [] ice_init_arfs+0x3a/0xe0 [ice] [] ice_vsi_cfg_def+0x607/0x850 [ice] [] ice_vsi_setup+0x5b/0x130 [ice] [] ice_init+0x1c1/0x460 [ice] [] ice_probe+0x2af/0x520 [ice] [] local_pci_probe+0x43/0xa0 [] work_for_cpu_fn+0x13/0x20 [] process_one_work+0x179/0x390 [] worker_thread+0x239/0x340 [] kthread+0xcc/0x100 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30 ...
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:jbd2: remove wrong sb->s_sequence checkJournal emptiness is not determined by sb->s_sequence == 0 but rather bysb->s_start == 0 (which is set a few lines above). Furthermore 0 is avalid transaction ID so the check can spuriously trigger. Remove theinvalid WARN_ON.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: avoid infinite loop to schedule delayed workerWe noticed the kworker in page_pool_release_retry() was wakenup repeatedly and infinitely in production because of thebuggy driver causing the inflight less than 0 and warningus in page_pool_inflight()[1].Since the inflight value goes negative, it means we shouldnot expect the whole page_pool to get back to work normally.This patch mitigates the adverse effect by not reschedulingthe kworker when detecting the inflight negative inpage_pool_release_retry().[1][Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages...[Mon Feb 10 20:36:11 2025] Call Trace:[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---Note: before this patch, the above calltrace would flood thedmesg due to repeated reschedule of release_dw kworker.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Fix memleak issue when GSO enabledAlways map the `skb` to the LS descriptor. Previously skb wasmapped to EXT descriptor when the number of fragments is zero withGSO enabled. Mapping the skb to EXT descriptor prevents it frombeing freed, leading to a memory leak
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/brokenA SCO connection without the proper voice_setting can causethe controller to lock up.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Add a upper bound on max_vclockssyzbot reported WARNING in max_vclocks_store.This occurs when the argument max is too large for kcalloc to handle.Extend the guard to guard against values that are too large forkcalloc
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kexec: Enable SMT before waking offline CPUsIf SMT is disabled or a partial SMT state is enabled, when a new kernelimage is loaded for kexec, on reboot the following warning is observed:kexec: Waking offline cpu 228.WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc[snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ecThis occurs as add_cpu() fails due to cpu_bootable() returning false forCPUs that fail the cpu_smt_thread_allowed() check or non primarythreads if SMT is disabled.Fix the issue by enabling SMT and resetting the number of SMT threads tothe number of threads per core, before attempting to wake up all presentCPUs.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.32.1).
-
Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.32.1).
-
Description: The demangler in GNU Libiberty allows remote attackers to cause a denial of service (infinite loop, stack overflow, and crash) via a cycle in the references of remembered mangled types.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- crash > 0-0 (version in image is 7.3.1-150500.3.4).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: ser: fix CAM leaks occurring in L2 resetThe CAM, meaning address CAM and bssid CAM here, will get leaks duringSER (system error recover) L2 reset process and ieee80211_restart_hw()which is called by L2 reset process eventually.The normal flow would be like-> add interface (acquire 1)-> enter ips (release 1)-> leave ips (acquire 1)-> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>The ieee80211_restart_hw() flow (under connection)-> ieee80211 reconfig-> add interface (acquire 1)-> leave ips (acquire 1)-> connection (occupy (A) + 2) <(B) 1 more leak>Originally, CAM is released before HW restart only if connection is undersecurity. Now, release CAM whatever connection it is to fix leak in (A).OTOH, check if CAM is already valid to avoid acquiring multiple times tofix (B).Besides, if AP mode, release address CAM of all stations before HW restart.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sfp: fix memory leak in sfp_probe()sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). Whendevm_add_action() fails, sfp is not freed, which leads to a memory leak.We should use devm_add_action_or_reset() instead of devm_add_action().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix possible refcount leak in tipc_sk_create()Free sk in case tipc_sk_insert() fails.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix refcount bug in sk_psock_get (2)Syzkaller reports refcount bug as follows:------------[ cut here ]------------refcount_t: saturated; leaking memory.WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19Modules linked in:CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel willreplaces TCP with SMC. In order to forward wakeupsmc socket waitqueue after fallback, kernel will setsclcsk->sk_user_data to origin smc socket insmc_fback_replace_callbacks().Later, in shutdown syscall, kernel will callssk_psock_get(), which treats the clcsk->sk_user_dataas psock type, triggering the refcnt warning.So, the root cause is that smc and psock, both will usesk_user_data field. So they will mismatch this fieldeasily.This patch solves it by using another bit(defined asSK_USER_DATA_PSOCK) in PTRMASK, to mark whethersk_user_data points to a psock object or not.This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e("net, sk_msg: Clear sk_user_data pointer on clone if tagged").For there will possibly be more flags in the sk_user_data field,this patch also refactor sk_user_data flags code to be more genericto improve its maintainability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix a memory leak in an error handling pathA bitmap_zalloc() must be balanced by a corresponding bitmap_free() in theerror handling path of afu_allocate_irqs().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/hpre - fix resource leak in remove processIn hpre_remove(), when the disable operation of qm sriov failed,the following logic should continue to be executed to release theremaining resources that have been allocated, instead of returningdirectly, otherwise there will be resource leakage.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: fix potential memory leakThis patch fix potential memory leak (clk_src) when function runinto last return NULL.s/free/kfree/ - Alex
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()The break of for_each_available_child_of_node() needs acorresponding of_node_put() when the reference 'child' is notused anymore. Here we do not need to call of_node_put() infail path as '!match' means no break.While the of_platform_device_create() will created a newreference by 'child' but it has considered the refcounting.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mipi-dsi: Detach devices when removing the hostWhenever the MIPI-DSI host is unregistered, the code ofmipi_dsi_host_unregister() loops over every device currently found on thatbus and will unregister it.However, it doesn't detach it from the bus first, which leads to all kindof resource leaks if the host wants to perform some clean up whenever adevice is detached.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocatedin failure, then `pcmdpriv->cmd_allocated_buf` will be not properlyreleased. Besides, considering there are only two error paths and thefirst one can directly return, so we do not need implicitly jump to the`exit` tag to execute the error handler.So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the errorpath to release the resource and simplified the return logic ofrtw_init_cmd_priv(). As there is no proper device to test with, no runtimetesting was performed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflowUDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.These registers are 32-bit hardware counters and the driver uses thesecounters to monitor the operational progress status for a channel, whentransferring more than 4GB of data it was observed that these countersoverflow and completion calculation of a operation gets affected and thetransfer hangs indefinitely.This commit adds changes to decrease the byte count for every completetransaction so that these registers never overflow and the proper bytecount statistics is maintained for ongoing transaction by the RT counters.Earlier uc->bcnt used to maintain a count of the completed bytes at driverside, since the RT counters maintain the statistics of current transactionnow, the maintenance of uc->bcnt is not necessary.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Prevent integer underflowBy using a ratio of delay to poll_enabled_time that is not integertime_remaining underflows and does not exit the loop as expected.As delay could be derived from DT and poll_enabled_time is definedin the driver this can easily happen.Use a signed iterator to make sure that the loop exits oncethe remaining time is negative.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()As the comment of pci_get_domain_bus_and_slot() says, it returnsa PCI device with refcount incremented, so it doesn't need tocall an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCIdevice needs to be put in the error path.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix possible memory leak in stmmac_dvr_probe()The bitmap_free() should be called to free priv->af_xdp_zc_qpswhen create_singlethread_workqueue() fails, otherwise there willbe a memory leak, so we add the err path error_wq_init to fix it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov5648: Free V4L2 fwnode data on unbindThe V4L2 fwnode data structure doesn't get freed on unbind, which leads toa memleak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix memory leak in nsim_bus_dev_new()If device_register() failed in nsim_bus_dev_new(), the value of referencein nsim_bus_dev->dev is 1. obj->name in nsim_bus_dev->dev will not bereleased.unreferenced object 0xffff88810352c480 (size 16): comm "echo", pid 5691, jiffies 4294945921 (age 133.270s) hex dump (first 16 bytes): 6e 65 74 64 65 76 73 69 6d 31 00 00 00 00 00 00 netdevsim1...... backtrace: [<000000005e2e5e26>] __kmalloc_node_track_caller+0x3a/0xb0 [<0000000094ca4fc8>] kvasprintf+0xc3/0x160 [<00000000aad09bcc>] kvasprintf_const+0x55/0x180 [<000000009bac868d>] kobject_set_name_vargs+0x56/0x150 [<000000007c1a5d70>] dev_set_name+0xbb/0xf0 [<00000000ad0d126b>] device_add+0x1f8/0x1cb0 [<00000000c222ae24>] new_device_store+0x3b6/0x5e0 [<0000000043593421>] bus_attr_store+0x72/0xa0 [<00000000cbb1833a>] sysfs_kf_write+0x106/0x160 [<00000000d0dedb8a>] kernfs_fop_write_iter+0x3a8/0x5a0 [<00000000770b66e2>] vfs_write+0x8f0/0xc80 [<0000000078bb39be>] ksys_write+0x106/0x210 [<00000000005e55a4>] do_syscall_64+0x35/0x80 [<00000000eaa40bbc>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()There is a memory leaks problem reported by kmemleak:unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes):ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace:[] __kmalloc+0x4d/0x150[] ubi_eba_create_table+0x76/0x170 [ubi][] ubi_resize_volume+0x1be/0xbc0 [ubi][] ubi_cdev_ioctl+0x701/0x1850 [ubi][] __x64_sys_ioctl+0x11d/0x170[] do_syscall_64+0x35/0x80[] entry_SYSCALL_64_after_hwframe+0x46/0xb0This is due to a mismatch between create and destroy interfaces, andin detail that "new_eba_tbl" created by ubi_eba_create_table() butdestroyed by kfree(), while will causing "new_eba_tbl->entries" notfreed.Fix it by replacing kfree(new_eba_tbl) withubi_eba_destroy_table(new_eba_tbl)
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix memory leak of device namesThe device names allocated by dev_set_name() need be freedbefore module unloading, but they can not be freed becausethe kobject's refcount which was set in device_initialize()has not be decreased to 0.As comment of device_add() says, if it fails, use onlyput_device() drop the refcount, then the name will befreed in kobejct_cleanup().device_del() and put_device() can be replaced withdevice_unregister(), so call it to unregister the addedsuccessfully devices, and just call put_device() to thenot added device.Add a release() function to device to avoid null release()function WARNING in device_release(), it's empty, becausethe context devices are freed together inhost1x_memory_context_list_free().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: Fix memory leak in rtw88_usbKmemleak shows the following leak arising from routine in the usbprobe routine:unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [] kmalloc_trace+0x26/0x90 [] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [] usb_probe_interface+0xdd/0x2e0 [usbcore] [] really_probe+0x18e/0x3d0 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xbf/0x1b0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x10e/0x210 [] driver_register+0x55/0xf0 [] usb_register_driver+0x88/0x140 [usbcore] [] do_one_initcall+0x43/0x210 [] do_init_module+0x4a/0x200 [] __do_sys_finit_module+0xac/0x120 [] do_syscall_64+0x56/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0The leak was verified to be real by unloading the driver, which resultedin a dangling pointer to the allocation.The allocated memory is freed in rtw_usb_intf_deinit().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: sifive: Fix refcount leak in sifive_gpio_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: amd: display: Fix memory leakageThis commit fixes memory leakage in dc_construct_ctx() function.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (xgene) Fix ioremap and memremap leakSmatch reports:drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:'ctx->pcc_comm_addr' from ioremap() not released on line: 757.This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),ioremap and memremap is not released, which may cause a leak.To fix this, ioremap and memremap is modified to devm_ioremap anddevm_memremap.[groeck: Fixed formatting and subject]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: Fix memory leak for detached NAPI queue.syzkaller reported [0] memory leaks of sk and skb related to the TUNdevice with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun);If we enable NAPI and multi-queue on a TUN device, we can put skb intotfile->sk.sk_write_queue after the queue is detached. We should preventit by checking tfile->detached before queuing skb.Note this must be done under tfile->sk.sk_write_queue.lock because write()and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there wouldbe a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb)Another solution is to call tun_queue_purge() when closing andreattaching the detached queue, but it could paper over anotherproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.[0]:unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdcunreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [<---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix skb leak in __skb_tstamp_tx()Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs withTX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks withzerocopy skbs. But it ended up adding a leak of its own. Whenskb_orphan_frags_rx() fails, the function just returns, leaking the skbit just cloned. Free it before returning.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: arc_uart: fix of_iomap leak in `arc_serial_probe`Smatch reports:drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:'port->membase' from of_iomap() not released on lines: 631.In arc_serial_probe(), if uart_add_one_port() fails,port->membase is not released, which would cause a resource leak.To fix this, I replace of_iomap with devm_platform_ioremap_resource.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspendsdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,driver unconditionally disables ecc_irq which is only enabled onthose asics enabling sdma ecc. This will introduce a warning insuspend cycle on those chips with sdma ip v4.0, while withoutsdma ecc. So this patch correct this.[ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu][ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246[ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000[ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000[ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006[ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390[ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105[ 7283.167032] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000[ 7283.167036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0[ 7283.167041] Call Trace:[ 7283.167046] [ 7283.167048] sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu][ 7283.167704] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu][ 7283.168296] amdgpu_device_suspend+0x103/0x180 [amdgpu][ 7283.168875] amdgpu_pmops_freeze+0x21/0x60 [amdgpu][ 7283.169464] pci_pm_freeze+0x54/0xc0
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()`req` is allocated in pcf50633_adc_async_read(), butadc_enqueue_request() could fail to insert the `req` into queue.We need to check the return value and free it in the case of failure.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: isotp: check CAN address family in isotp_bind()Add missing check to block non-AF_CAN binds.Syzbot created some code which matched the right sockaddr struct sizebut used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address familyfield:bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^This has no funtional impact but the userspace should be notified aboutthe wrong address family field content.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle case when repair happens with dev-replace[BUG]There is a bug report that a BUG_ON() in btrfs_repair_io_failure()(originally repair_io_failure() in v6.0 kernel) got triggered whenreplacing a unreliable disk: BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3 kernel BUG at fs/btrfs/extent_io.c:2380! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2 Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs] Call Trace: clean_io_failure+0x14d/0x180 [btrfs] end_bio_extent_readpage+0x412/0x6e0 [btrfs] ? __switch_to+0x106/0x420 process_one_work+0x1c7/0x380 worker_thread+0x4d/0x380 ? rescuer_thread+0x3a0/0x3a0 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30[CAUSE]Before the BUG_ON(), we got some read errors from the replace targetfirst, note the mirror number (3, which is beyond RAID1 duplication,thus it's read from the replace target device).Then at the BUG_ON() location, we are trying to writeback the repairedsectors back the failed device.The check looks like this: ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical, &map_length, &bioc, mirror_num); if (ret) goto out_counter_dec; BUG_ON(mirror_num != bioc->mirror_num);But inside btrfs_map_block(), we can modify bioc->mirror_num especiallyfor dev-replace: if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 && !need_full_stripe(op) && dev_replace->tgtdev != NULL) { ret = get_extra_mirror_from_replace(fs_info, logical, *length, dev_replace->srcdev->devid, &mirror_num, &physical_to_patch_in_first_stripe); patch_the_first_stripe_for_dev_replace = 1; }Thus if we're repairing the replace target device, we're going totrigger that BUG_ON().But in reality, the read failure from the replace target device may bethat, our replace hasn't reached the range we're reading, thus we'rereading garbage, but with replace running, the range would be properlyfilled later.Thus in that case, we don't need to do anything but let the replaceroutine to handle it.[FIX]Instead of a BUG_ON(), just skip the repair if we're repairing thedevice replace target device.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: tuners: qt1010: replace BUG_ON with a regular errorBUG_ON is unnecessary here, and in addition it confuses smatch.Replacing this with an error return help resolve this smatchwarning:drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()The buffer in the loop should be released under the exception path,otherwise there may be a memory leak here.To mitigate this, free the buffer when allegro_alloc_buffer fails.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix memory leak in dccp_feat_change_recvIf dccp_feat_push_confirm() fails after new value for SP feature was acceptedwithout reconciliation ('entry == NULL' branch), memory allocated for that valuewith dccp_feat_clone_sp_val() is never freed.Here is the kmemleak stack for this:unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1Clean up the allocated memory in case of dccp_feat_push_confirm() failureand bail out with an error reset code.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRLCurrently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'variable, and a SETREGSET call with a length of zero will leave thisuninitialized. Consequently tagged_addr_ctrl_set() will consume anarbitrary value, potentially leaking up to 64 bits of memory from thekernel stack. The read is limited to a specific slot on the stack, andthe issue does not provide a write mechanism.As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero andrejects other values, a partial SETREGSET attempt will randomly succeedor fail depending on the value of the uninitialized value, and theexposure is significantly limited.Fix this by initializing the temporary value before copying the regsetfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existingvalue of the tagged address ctrl will be retained.The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in theuser_aarch64_view used by a native AArch64 task to manipulate anothernative AArch64 task. As get_tagged_addr_ctrl() only returns an errorvalue when called for a compat task, tagged_addr_ctrl_get() andtagged_addr_ctrl_set() should never observe an error value fromget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate thatsuch an error would be unexpected, and error handlnig is not missing ineither case.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: rockchip_saradc: fix information leak in triggered bufferThe 'data' local struct is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- iproute2 > 0-0 (version in image is 5.14-150400.3.3.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libpcap1 > 0-0 (version in image is 1.10.1-150400.3.6.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occurscsi_execute_cmd() function can return both negative (linux codes) andpositive (scsi_cmnd result field) error codes.Currently the driver just passes error codes of scsi_execute_cmd() tohwmon core, which is incorrect because hwmon only checks for negativeerror codes. This leads to hwmon reporting uninitialized data touserspace in case of SCSI errors (for example if the disk drive wasdisconnected).This patch checks scsi_execute_cmd() output and returns -EIO if it'serror code is positive.[groeck: Avoid inline variable declaration for portability]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: lock the socket in rose_bind()syzbot reported a soft lockup in rose_loopback_timer(),with a repro calling bind() from multiple threads.rose_bind() must lock the socket to avoid this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- augeas > 0-0 (version in image is 1.12.0-150400.3.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: Fix unsafe attribute parsing in output_userspace()This patch replaces the manual Netlink attribute iteration inoutput_userspace() with nla_for_each_nested(), which ensures that onlywell-formed attributes are processed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: disable napi on driver removalA warning on driver removal started occurring after commit 9dd05df8403b("net: warn if NAPI instance wasn't shut down"). Disable tx napi beforedeleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7eTested with mt7921e but the same pattern can be actually applied to othermt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabledin their *_dma_init() functions and only toggled off and on again insidetheir suspend/resume/reset paths. So it should be okay to disable txnapi in such a generic way.Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: spinand: fix memory leak of ECC engine confMemory allocated for the ECC engine conf is not released during spinandcleanup. Below kmemleak trace is seen for this memory leak:unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160Fix the leak by calling nanddev_ecc_engine_cleanup() insidespinand_cleanup().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix another leak in the submit error pathput_unused_fd() doesn't free the installed file, if we've already donefd_install(). So we need to also free the sync_file.Patchwork: https://patchwork.freedesktop.org/patch/653583/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()with the proper length instead of 0. This bug triggers this warningon a system with IOMMU enabled:WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170RIP: 0010:__iommu_dma_unmap+0x159/0x170Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00RSP: 0018:ff22d31181150c88 EFLAGS: 00010206RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0PKRU: 55555554Call Trace:? show_regs+0x6d/0x80? __warn+0x89/0x160? __iommu_dma_unmap+0x159/0x170? report_bug+0x17e/0x1b0? handle_bug+0x46/0x90? exc_invalid_op+0x18/0x80? asm_exc_invalid_op+0x1b/0x20? __iommu_dma_unmap+0x159/0x170? __iommu_dma_unmap+0xb3/0x170iommu_dma_unmap_page+0x4f/0x100dma_unmap_page_attrs+0x52/0x220? srso_alias_return_thunk+0x5/0xfbef5? xdp_return_frame+0x2e/0xd0bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]bnxt_poll+0xd3/0x1e0 [bnxt_en]
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold the array of `struct comedi_insn`, getting the length from the`n_insns` member of the `struct comedi_insnlist` supplied by the user.The allocation will fail with a WARNING and a stack dump if it is toolarge.Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`value is unreasonable.Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: validate PHY address before useThe ASIX driver reads the PHY address from the USB device viaasix_read_phy_addr(). A malicious or faulty device can return aninvalid address (>= PHY_MAX_ADDR), which causes a warning inmdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76Validate the PHY address in asix_read_phy_addr() and remove thenow-redundant check in ax88172a.c.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libpython3_11-1_0 < 3.11.14-150400.9.69.1 (version in image is 3.11.13-150400.9.66.1).
-
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- gettext-runtime > 0-0 (version in image is 0.20.2-1.43).
-
Description: golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.
Packages affected:
- sle-module-containers-release == 15.5 (version in image is 15.5-150500.43.2).
- docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- curl > 0-0 (version in image is 8.14.1-150400.5.69.1).
-
Description: During an address list folding when a separating comma ends up on a folded line and that line is to be unicode-encoded then the separator itself is also unicode-encoded. Expected behavior is that the separating comma remains a plan comma. This can result in the address header being misinterpreted by some mail servers.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).
-
Description: A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libssh-config > 0-0 (version in image is 0.9.8-150400.3.9.1).
-
Description: When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libxml2-2 > 0-0 (version in image is 2.10.3-150500.5.32.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.1).
-
Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- vim > 0-0 (version in image is 9.1.1629-150500.20.33.1).
-
Description: In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix percpu counter block leak on error path when creating new netnsHere is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_tableAnd it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # failsthere is no freeing of the counter block on xt_register_table fail.Note: xt_percpu_counter_free should be called to free it like we do indo_replace through cleanup_entry helper (or in __ip6t_unregister_table).Probability of hitting this error path is low AFAICS (xt_register_tablecan only return ENOMEM here, as it is not replacing anything, as we arecreating new netns, and it is hard to imagine that all previousallocations succeeded and after that one in xt_register_table failed).But it's worth fixing even the rare leak.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Initialize cfid->tcon before performing network opsAvoid leaking a tcon ref when a lease break races with opening thecached directory. Processing the leak break might take a reference tothe tcon in cached_dir_lease_break() and then fail to release the ref incached_dir_offload_close, since cfid->tcon is still NULL.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sound/virtio: Fix cancel_sync warnings on uninitialized work_structsBetty reported hitting the following warning:[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182...[ 8.713282][ T221] Call trace:[ 8.713365][ T221] __flush_work+0x8d0/0x914[ 8.713468][ T221] __cancel_work_sync+0xac/0xfc[ 8.713570][ T221] cancel_work_sync+0x24/0x34[ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.714035][ T221] virtio_dev_probe+0x28c/0x390[ 8.714139][ T221] really_probe+0x1bc/0x4c8...It seems we're hitting the error path in virtsnd_probe(), whichtriggers a virtsnd_remove() which iterates over the substreamscalling cancel_work_sync() on the elapsed_period work_struct.Looking at the code, from earlier in:virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()We set snd->nsubstreams, allocate the snd->substreams, and ifwe then hit an error on the info allocation or something invirtsnd_ctl_query_info() fails, we will exit without havinginitialized the elapsed_period work_struct.When that error path unwinds we then call virtsnd_remove()which as long as the substreams array is allocated, will iteratethrough calling cancel_work_sync() on the uninitialized workstruct hitting this warning.Takashi Iwai suggested this fix, which initializes the substreamsstructure right after allocation, so that if we hit the errorpaths we avoid trying to cleanup uninitialized data.Note: I have not yet managed to reproduce the issue myself, sothis patch has had limited testing.Feedback or thoughts would be appreciated!
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: st: Fix array overflow in st_setup()Change the array size to follow parms size instead of a fixed value.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.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:xfrm: Reinject transport-mode packets through workqueueThe following warning is displayed when the tcp6-multi-diffip11 stresstest case of the LTP test suite is tested:watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : des3_ede_encrypt+0x27c/0x460 [libdes]lr : 0x3fsp : ffff80000ceaa1b0x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003bx23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001bx5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872Call trace: des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_genicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184Get softirq info by bcc tool:./softirqs -NT 10Tracing soft irq event time... Hit Ctrl-C to end.15:34:34SOFTIRQ TOTAL_nsecsblock 158990timer 20030920sched 46577080net_rx 676746820tasklet 990606765015:34:45SOFTIRQ TOTAL_nsecsblock 86100sched 38849790net_rx ---truncated---
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: reduce WARN to dev_dbg() in callbackThe warn is triggered on a known race condition, documented in the code abovethe test, that is correctly handled. Using WARN() hinders automated testing.Reducing severity.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: report devlink_port_type_warn source devicedevlink_port_type_warn is scheduled for port devlink and warningwhen the port type is not set. But from this warning it is not easyfound out which device (driver) has no devlink port set.[ 3709.975552] Type was not set for devlink port.[ 3709.975579] WARNING: CPU: 1 PID: 13092 at net/devlink/leftover.c:6775 devlink_port_type_warn+0x11/0x20[ 3709.993967] Modules linked in: openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink bluetooth rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs vhost_net vhost vhost_iotlb tap tun bridge stp llc qrtr intel_rapl_msr intel_rapl_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal mlx5_ib intel_powerclamp coretemp dell_wmi ledtrig_audio sparse_keymap ipmi_ssif kvm_intel ib_uverbs rfkill ib_core video kvm iTCO_wdt acpi_ipmi intel_vsec irqbypass ipmi_si iTCO_vendor_support dcdbas ipmi_devintf mei_me ipmi_msghandler rapl mei intel_cstate isst_if_mmio isst_if_mbox_pci dell_smbios intel_uncore isst_if_common i2c_i801 dell_wmi_descriptor wmi_bmof i2c_smbus intel_pch_thermal pcspkr acpi_power_meter xfs libcrc32c sd_mod sg nvme_tcp mgag200 i2c_algo_bit nvme_fabrics drm_shmem_helper drm_kms_helper nvme syscopyarea ahci sysfillrect sysimgblt nvme_core fb_sys_fops crct10dif_pclmul libahci mlx5_core sfc crc32_pclmul nvme_common drm[ 3709.994030] crc32c_intel mtd t10_pi mlxfw libata tg3 mdio megaraid_sas psample ghash_clmulni_intel pci_hyperv_intf wmi dm_multipath sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse[ 3710.108431] CPU: 1 PID: 13092 Comm: kworker/1:1 Kdump: loaded Not tainted 5.14.0-319.el9.x86_64 #1[ 3710.108435] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022[ 3710.108437] Workqueue: events devlink_port_type_warn[ 3710.108440] RIP: 0010:devlink_port_type_warn+0x11/0x20[ 3710.108443] Code: 84 76 fe ff ff 48 c7 03 20 0e 1a ad 31 c0 e9 96 fd ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 48 c7 c7 18 24 4e ad e8 ef 71 62 ff <0f> 0b c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f6 87[ 3710.108445] RSP: 0018:ff3b6d2e8b3c7e90 EFLAGS: 00010282[ 3710.108447] RAX: 0000000000000000 RBX: ff366d6580127080 RCX: 0000000000000027[ 3710.108448] RDX: 0000000000000027 RSI: 00000000ffff86de RDI: ff366d753f41f8c8[ 3710.108449] RBP: ff366d658ff5a0c0 R08: ff366d753f41f8c0 R09: ff3b6d2e8b3c7e18[ 3710.108450] R10: 0000000000000001 R11: 0000000000000023 R12: ff366d753f430600[ 3710.108451] R13: ff366d753f436900 R14: 0000000000000000 R15: ff366d753f436905[ 3710.108452] FS: 0000000000000000(0000) GS:ff366d753f400000(0000) knlGS:0000000000000000[ 3710.108453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3710.108454] CR2: 00007f1c57bc74e0 CR3: 000000111d26a001 CR4: 0000000000773ee0[ 3710.108456] PKRU: 55555554[ 3710.108457] Call Trace:[ 3710.108458] [ 3710.108459] process_one_work+0x1e2/0x3b0[ 3710.108466] ? rescuer_thread+0x390/0x390[ 3710.108468] worker_thread+0x50/0x3a0[ 3710.108471] ? rescuer_thread+0x390/0x390[ 3710.108473] kthread+0xdd/0x100[ 3710.108477] ? kthread_complete_and_exit+0x20/0x20[ 3710.108479] ret_from_fork+0x1f/0x30[ 3710.108485] [ 3710.108486] ---[ end trace 1b4b23cd0c65d6a0 ]---After patch:[ 402.473064] ice 0000:41:00.0: Type was not set for devlink port.[ 402.473064] ice 0000:41:00.1: Type was not set for devlink port.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATINGIn fscache_create_volume(), there is a missing memory barrier between thebit-clearing operation and the wake-up operation. This may cause asituation where, after a wake-up, the bit-clearing operation hasn't beendetected yet, leading to an indefinite wait. The triggering process is asfollows: [cookie1] [cookie2] [volume_work]fscache_perform_lookup fscache_create_volume fscache_perform_lookup fscache_create_volume fscache_create_volume_work cachefiles_acquire_volume clear_and_wake_up_bit test_and_set_bit test_and_set_bit goto maybe_wait goto no_waitIn the above process, cookie1 and cookie2 has the same volume. When cookie1enters the -no_wait- process, it will clear the bit and wake up the waitingprocess. If a barrier is missing, it may cause cookie2 to remain in the-wait- process indefinitely.In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() infscache_create_volume_work()"), barriers were added to similar operationsin fscache_create_volume_work(), but fscache_create_volume() was missed.By combining the clear and wake operations into clear_and_wake_up_bit() tofix this issue.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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.5 (version in image is 15.5-150500.61.4.1).
- elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix bpf_sk_select_reuseport() memory leakAs pointed out in the original comment, lookup in sockmap can return a TCPESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPFset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cbdoes not imply a non-refcounted socket.Drop sk's reference in both error paths.unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: socket: Lookup orig tuple for IPv6 SNATnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets torestore the original 5-tuple in case of SNAT, to be able to find theright socket (if any). Then socket_match() can correctly check whetherthe socket was transparent.However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks thisconntrack lookup, making xt_socket fail to match on the socket when thepacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, aspods' addresses are in the fd00::/8 ULA subnet and need to be replacedwith the node's external address. Cilium leverages Envoy to enforce L7policies, and Envoy uses transparent sockets. Cilium inserts an iptablesprerouting rule that matches on `-m socket --transparent` and redirectsthe packets to localhost, but it fails to match SNATed IPv6 packets dueto that missing conntrack lookup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock... or we risk stealing final mntput from sync umount - raising mnt_countafter umount(2) has verified that victim is not busy, but before ithas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't seethat it's safe to quietly undo mnt_count increment and leaves droppingthe reference to caller, where it'll be a full-blown mntput().Check under mount_lock is needed; leaving the current one done beforetaking that makes no sense - it's nowhere near common enough to botherwith.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- libpython3_11-1_0 < 3.11.14-150400.9.69.1 (version in image is 3.11.13-150400.9.66.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.5 (version in image is 15.5-150500.61.4.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.5 (version in image is 15.5-150500.61.4.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:RDMA/cm: Fix leaking the multicast GID table referenceIf the CM ID is destroyed while the CM event for multicast creating isstill queued the cancel_work_sync() will prevent the work from runningwhich also prevents destroying the ah_attr. This leaks a refcount andtriggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886Destroy the ah_attr after canceling the work, it is safe to call thistwice.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: check error for register_netdev() on initCurrent init logic ignores the error code from register_netdev(),which will cause WARN_ON() on attempt to unregister it, if there was one,and there is no info for the user that the creation of the netdev failed.WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10...[ 3707.563641] unregister_netdev+0x1c/0x30[ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf][ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf][ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf][ 3707.563739] idpf_remove+0xbf/0x780 [idpf][ 3707.563769] pci_device_remove+0xab/0x1e0[ 3707.563786] device_release_driver_internal+0x371/0x530[ 3707.563803] driver_detach+0xbf/0x180[ 3707.563816] bus_remove_driver+0x11b/0x2a0[ 3707.563829] pci_unregister_driver+0x2a/0x250Introduce an error check and log the vport number and error code.On removal make sure to check VPORT_REG_NETDEV flag prior to callingunregister and free on the netdev.Add local variables for idx, vport_config and netdev for readability.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Balance device refcount when destroying devicesUsing device_find_child() to lookup the proper SCMI device to destroycauses an unbalance in device refcount, since device_find_child() calls animplicit get_device(): this, in turns, inhibits the call of the providedrelease methods upon devices destruction.As a consequence, one of the structures that is not freed properly upondestruction is the internal struct device_private dev->p populated by thedrivers subsystem core.KMemleak detects this situation since loading/unloding some SCMI drivercauses related devices to be created/destroyed without calling anydevice_release method.unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0device_add+0x954/0x12d0:kmalloc_noprof at include/linux/slab.h:901(inlined by) kzalloc_noprof at include/linux/slab.h:1037(inlined by) device_private_init at drivers/base/core.c:3510(inlined by) device_add at drivers/base/core.c:3561Balance device refcount by issuing a put_device() on devices found viadevice_find_child().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: reject on-disk inodes of an unsupported typeSyzbot has reported the following BUG:kernel BUG at fs/inode.c:668!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014RIP: 0010:clear_inode+0x168/0x190Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7fRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlyingJFS inode of unknown type. According to JFS layout description fromhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to15 are reserved for future extensions and should not be encountered on a validfilesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix debug actions orderThe order of actions taken for debug was implemented incorrectly.Now we implemented the dump split and do the FW reset only in themiddle of the dump (rather than the FW killing itself on error.)As a result, some of the actions taken when applying the configwill now crash the device, so we need to fix the order.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid0, raid10: Don't set discard sectors for request queueIt should use disk_stack_limits to get a proper max_discard_sectorsrather than setting a value by stack drivers.And there is a bug. If all member disks are rotational devices,raid0/raid10 set max_discard_sectors. So the member devices arenot ssd/nvme, but raid0/raid10 export the wrong value. It reportswarning messages in function __blkdev_issue_discard when mkfs.xfslike this:[ 4616.022599] ------------[ cut here ]------------[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0[ 4616.236689] Call Trace:[ 4616.239428] blkdev_issue_discard+0x52/0xb0[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00[ 4616.248883] blkdev_ioctl+0x116/0x280[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0[ 4616.257163] do_syscall_64+0x5c/0x90[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690[ 4616.270527] ? do_syscall_64+0x69/0x90[ 4616.274717] ? exc_page_fault+0x62/0x150[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 4616.284748] RIP: 0033:0x7f9a55398c6b
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix uninit-value access of imap allocated in the diMount() functionsyzbot reports that hex_dump_to_buffer is using uninit-value:=====================================================BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156evict+0x723/0xd10 fs/inode.c:796iput_final fs/inode.c:1946 [inline]iput+0x97b/0xdb0 fs/inode.c:1972txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733kthread+0x6b9/0xef0 kernel/kthread.c:464ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Uninit was created at:slab_post_alloc_hook mm/slub.c:4121 [inline]slab_alloc_node mm/slub.c:4164 [inline]__kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320kmalloc_noprof include/linux/slab.h:901 [inline]diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636get_tree_bdev+0x37/0x50 fs/super.c:1659jfs_get_tree+0x34/0x40 fs/jfs/super.c:635vfs_get_tree+0xb1/0x5a0 fs/super.c:1814do_new_mount+0x71f/0x15e0 fs/namespace.c:3560path_mount+0x742/0x1f10 fs/namespace.c:3887do_mount fs/namespace.c:3900 [inline]__do_sys_mount fs/namespace.c:4111 [inline]__se_sys_mount+0x71f/0x800 fs/namespace.c:4088__x64_sys_mount+0xe4/0x150 fs/namespace.c:4088x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7f=====================================================The reason is that imap is not properly initialized after memoryallocation. It will cause the snprintf() function to write uninitializeddata into linebuf within hex_dump_to_buffer().Fix this by using kzalloc instead of kmalloc to clear its content at thebeginning in diMount().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Fix early region not updated correctlyThe shadow's page table is not updated when PTE_RPN_SHIFT is 24and PAGE_SHIFT is 12. It not only causes false positives butalso false negative as shown the following text.Fix it by bringing the logic of kasan_early_shadow_page_entry here.1. False Positive:==================================================================BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50Write of size 16 at addr f57f3be0 by task swapper/0/1CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1Call Trace:[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0[c80d1cc0] [c03018a4] memset+0x34/0x90[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0[c80d1db0] [c2036580] init_sd+0xc4/0x1d0[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384[c80d1ef0] [c0004b14] kernel_init+0x24/0x170[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================2. False Negative (with KASAN tests):==================================================================Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan==================================================================After fix: ok 1 - kasan
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:highmem: fix checks in __kmap_local_sched_{in,out}When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} checkthat even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots areinitialized with 0 value, but the check is done with pte_none. 0 ptehowever does not necessarily mean that pte_none will return true. e.g.on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7fFix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Fix FFA device names for logical partitionsEach physical partition can provide multiple services each with UUID.Each such service can be presented as logical partition with a uniquecombination of VM ID and UUID. The number of distinct UUID in a systemwill be less than or equal to the number of logical partitions.However, currently it fails to register more than one logical partitionor service within a physical partition as the device name contains onlyVM ID while both VM ID and UUID are maintained in the partition information.The kernel complains with the below message: | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001' | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8 | Hardware name: FVP Base RevC (DT) | Call trace: | dump_backtrace+0xf8/0x118 | show_stack+0x18/0x24 | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | sysfs_create_dir_ns+0xe0/0x13c | kobject_add_internal+0x220/0x3d4 | kobject_add+0x94/0x100 | device_add+0x144/0x5d8 | device_register+0x20/0x30 | ffa_device_register+0x88/0xd8 | ffa_setup_partitions+0x108/0x1b8 | ffa_init+0x2ec/0x3a4 | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to | register things with the same name in the same directory. | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17 | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001By virtue of being random enough to avoid collisions when generated in adistributed system, there is no way to compress UUID keys to the numberof bits required to identify each. We can eliminate '-' in the name butit is not worth eliminating 4 bytes and add unnecessary logic for doingthat. Also v1.0 doesn't provide the UUID of the partitions which makesit hard to use the same for the device name.So to keep it simple, let us alloc an ID using ida_alloc() and append thesame to "arm-ffa" to make up a unique device name. Also stash the id valuein ffa_dev to help freeing the ID later when the device is destroyed.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl logIt's trivial for user to trigger "verifier log line truncated" warning,as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are atleast two pieces of user-provided information that can be output throughthis buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.Verifier log buffer should be properly sized for typical verifier stateoutput. But it's sort-of expected that this buffer won't be long enoughin some circumstances. So let's drop the check. In any case code willwork correctly, at worst truncating a part of a single line output.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: remove BUG_ON()'s in add_new_free_space()At add_new_free_space() we have these BUG_ON()'s that are there to dealwith any failure to add free space to the in memory free space cache.Such failures are mostly -ENOMEM that should be very rare. However there'sno need to have these BUG_ON()'s, we can just return any error to thecaller and all callers and their upper call chain are already dealing witherrors.So just make add_new_free_space() return any errors, while removing theBUG_ON()'s, and returning the total amount of added free space to anoptional u64 pointer argument.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Silence a warning in btf_type_id_size()syzbot reported a warning in [1] with the following stacktrace: WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... Call Trace: map_check_btf kernel/bpf/syscall.c:1024 [inline] map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198 __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040 __do_sys_bpf kernel/bpf/syscall.c:5162 [inline] __se_sys_bpf kernel/bpf/syscall.c:5160 [inline] __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdWith the following btf [1] DECL_TAG 'a' type_id=4 component_idx=-1 [2] PTR '(anon)' type_id=0 [3] TYPE_TAG 'a' type_id=2 [4] VAR 'a' type_id=3, linkage=staticand when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),the following WARN_ON_ONCE in btf_type_id_size() is triggered: if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) && !btf_type_is_var(size_type))) return NULL;Note that 'return NULL' is the correct behavior as we don't wanta DECL_TAG type to be used as a btf_{key,value}_type_id evenfor the case like 'DECL_TAG -> STRUCT'. So thereis no correctness issue here, we just want to silence warning.To silence the warning, I added DECL_TAG as one of kinds inbtf_type_nosize() which will cause btf_type_id_size() returningNULL earlier without the warning. [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Don't retire aborted MMIO instructionReturning an abort to the guest for an unsupported MMIO access is adocumented feature of the KVM UAPI. Nevertheless, it's clear that thisplumbing has seen limited testing, since userspace can trivially cause aWARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The splat is complaining that KVM is advancing PC while an exception ispending, i.e. that KVM is retiring the MMIO instruction despite apending synchronous external abort. Womp womp.Fix the glaring UAPI bug by skipping over all the MMIO emulation incase there is a pending synchronous exception. Note that while userspaceis capable of pending an asynchronous exception (SError, IRQ, or FIQ),it is still safe to retire the MMIO instruction in this case as (1) theyare by definition asynchronous, and (2) KVM relies on hardware supportfor pending/delivering these exceptions instead of the software statemachine for advancing PC.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-development-tools-release == 15.5 (version in image is 15.5-150500.43.2).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Remove WARN_ON in functionfs_bindThis commit addresses an issue related to below kernel panic wherepanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ONin functionsfs_bind, which easily leads to the following scenarios.1.adb_write in adbd 2. UDC write via configfs ================= =====================->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register()->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function()->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE>The adb_open, adb_read, and adb_write operations are invoked from thedaemon, but trying to bind the function is a process that is invoked byUDC write through configfs, which opens up the possibility of a racecondition between the two paths. In this race scenario, the kernel panicoccurs due to the WARN_ON from functionfs_bind when panic_on_warn isenabled. This commit fixes the kernel panic by removing the unnecessaryWARN_ON.Kernel panic - not syncing: kernel: panic_on_warn set ...[ 14.542395] Call trace:[ 14.542464] ffs_func_bind+0x1c8/0x14a8[ 14.542468] usb_add_function+0xcc/0x1f0[ 14.542473] configfs_composite_bind+0x468/0x588[ 14.542478] gadget_bind_driver+0x108/0x27c[ 14.542483] really_probe+0x190/0x374[ 14.542488] __driver_probe_device+0xa0/0x12c[ 14.542492] driver_probe_device+0x3c/0x220[ 14.542498] __driver_attach+0x11c/0x1fc[ 14.542502] bus_for_each_dev+0x104/0x160[ 14.542506] driver_attach+0x24/0x34[ 14.542510] bus_add_driver+0x154/0x270[ 14.542514] driver_register+0x68/0x104[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144[ 14.542526] configfs_write_iter+0xf0/0x138
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: do not update checksum in bnxt_xdp_build_skb()The bnxt_rx_pkt() updates ip_summed value at the end if checksum offloadis enabled.When the XDP-MB program is attached and it returns XDP_PASS, thebnxt_xdp_build_skb() is called to update skb_shared_info.The main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,but it updates ip_summed value too if checksum offload is enabled.This is actually duplicate work.When the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summedis CHECKSUM_NONE or not.It means that ip_summed should be CHECKSUM_NONE at this moment.But ip_summed may already be updated to CHECKSUM_UNNECESSARY in theXDP-MB-PASS path.So the by skb_checksum_none_assert() WARNS about it.This is duplicate work and updating ip_summed in thebnxt_xdp_build_skb() is not needed.Splat looks like:WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]Modules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G W 6.14.0-rc4+ #27Tainted: [W]=WARNHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b fRSP: 0018:ffff88881ba09928 EFLAGS: 00010202RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0PKRU: 55555554Call Trace: ? __warn+0xcd/0x2f0 ? bnxt_rx_pkt+0x479b/0x7610 ? report_bug+0x326/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? bnxt_rx_pkt+0x479b/0x7610 ? bnxt_rx_pkt+0x3e41/0x7610 ? __pfx_bnxt_rx_pkt+0x10/0x10 ? napi_complete_done+0x2cf/0x7d0 __bnxt_poll_work+0x4e8/0x1220 ? __pfx___bnxt_poll_work+0x10/0x10 ? __pfx_mark_lock.part.0+0x10/0x10 bnxt_poll_p5+0x36a/0xfa0 ? __pfx_bnxt_poll_p5+0x10/0x10 __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x899/0xd00...Following ping.py patch adds xdp-mb-pass case. so ping.py is goingto be able to reproduce this issue.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix out-of-bound memcpy() during ethtool -wWhen retrieving the FW coredump using ethtool, it can sometimes causememory corruption:BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]ethtool_get_dump_data+0xdc/0x1a0__dev_ethtool+0xa1e/0x1af0dev_ethtool+0xa8/0x170dev_ioctl+0x1b5/0x580sock_do_ioctl+0xab/0xf0sock_ioctl+0x1ce/0x2e0__x64_sys_ioctl+0x87/0xc0do_syscall_64+0x5c/0xf0entry_SYSCALL_64_after_hwframe+0x78/0x80...This happens when copying the coredump segment list inbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.The info->dest_buf buffer is allocated based on the number of coredumpsegments returned by the FW. The segment list is then DMA'ed bythe FW and the length of the DMA is returned by FW. The driver thencopies this DMA'ed segment list to info->dest_buf.In some cases, this DMA length may exceed the info->dest_buf lengthand cause the above BUG condition. Fix it by capping the copylength to not exceed the length of info->dest_buf. The extraDMA data contains no useful information.This code path is shared for the HWRM_DBG_COREDUMP_LIST and theHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is differentfor these 2 FW commands. To simplify the logic, we need to movethe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVEup, so that the new check to cap the copy length will work for bothcommands.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()Nouveau is mostly designed in a way that it's expected that fences onlyever get signaled through nouveau_fence_signal(). However, in at leastone other place, nouveau_fence_done(), can signal fences, too. If thathappens (race) a signaled fence remains in the pending list for a while,until it gets removed by nouveau_fence_update().Should nouveau_fence_context_kill() run in the meantime, this would bea bug because the function would attempt to set an error code on analready signaled fence.Have nouveau_fence_context_kill() check for a fence being signaled.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Annotate FDB data racesThe 'used' and 'updated' fields in the FDB entry structure can beaccessed concurrently by multiple threads, leading to reports such as[1]. Can be reproduced using [2].Suppress these reports by annotating these accesses usingREAD_ONCE() / WRITE_ONCE().[1]BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmitwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6fReported by Kernel Concurrency Sanitizer on:CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabledWhen attempting to enable MQPRIO while HTB offload is alreadyconfigured, the driver currently returns `-EINVAL` and triggers a`WARN_ON`, leading to an unnecessary call trace.Update the code to handle this case more gracefully by returning`-EOPNOTSUPP` instead, while also providing a helpful user message.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Set dma_mask for ffa devicesSet dma_mask for FFA devices, otherwise DMA allocation using the device pointerlead to following warning:WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx231xx: set device_caps for 417The video_device for the MPEG encoder did not set device_caps.Add this, otherwise the video device can't be registered (you get aWARN_ON instead).Not seen before since currently 417 support is disabled, but I foundthis while experimenting with it.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().As syzbot reported [0], mpls_route_input_rcu() can be calledfrom mpls_getroute(), where is under RTNL.net->mpls.platform_label is only updated under RTNL.Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() tosilence the splat.[0]:WARNING: suspicious RCU usage6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ----------------------------net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961stack backtrace:CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0a2818e969Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Prevent access to vCPU events before initAnother day, another syzkaller bug. KVM erroneously allows userspace topend vCPU events for a vCPU that hasn't been initialized yet, leading toKVM interpreting a bunch of uninitialized garbage for routing /injecting the exception.In one case the injection code and the hyp disagree on whether the vCPUhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)Reject the ioctls outright as no sane VMM would call these beforeKVM_ARM_VCPU_INIT anyway. Even if it did the exception would've beenthrown away by the eventual reset of the vCPU's state.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource()As 'kdata.num' is user-controlled data, if user tries to allocatememory larger than(>=) MAX_ORDER, then kcalloc() will fail, itcreates a stack trace and messes up dmesg with a warning.Call trace:-> privcmd_ioctl--> privcmd_ioctl_mmap_resourceAdd __GFP_NOWARN in order to avoid too large allocation warning.This is detected by static analysis using smatch.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default < 5.14.21-150500.55.127.1 (version in image is 5.14.21-150500.55.124.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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- 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.5 (version in image is 15.5-150500.61.4.1).
- elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_ring: Fix data race by tagging event_triggered as racy for KCSANsyzbot reports a data-race when accessing the event_triggered, here is thesimplified stack when the issue occurred:==================================================================BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayedwrite to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline]read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline]value changed: 0x01 -> 0x00==================================================================When the data race occurs, the function virtqueue_enable_cb_delayed() setsevent_triggered to false, and virtqueue_disable_cb_split/packed() reads itas false due to the race condition. Since event_triggered is an unreliablehint used for optimization, this should only cause the driver temporarilysuggest that the device not send an interrupt notification when the eventindex is used.Fix this KCSAN reported data-race issue by explicitly tagging the access asdata_racy.
Packages affected:
- sles-release == 15.5 (version in image is 15.5-150500.61.4.1).
- kernel-default > 0-0 (version in image is 5.14.21-150500.55.124.1).