suse-manager-server-4-3-byos-v20260127-x86-64 CVE scan on 2026-01-27T02:31:03+00:00

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

Description: Untrusted data inclusion in pg_dump in PostgreSQL allows a malicious superuser of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands. pg_dumpall is also affected. pg_restore is affected when used to generate a plain-format dump. This is similar to MySQL CVE-2024-21096. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.

Packages affected:

postgresql14 > 0-0 (version in image is 14.19-150200.5.61.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

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

Description: Improper neutralization of newlines in pg_dump in PostgreSQL allows a user of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands inside a purpose-crafted object name. The same attacks can achieve SQL injection as a superuser of the restore target server. pg_dumpall, pg_restore, and pg_upgrade are also affected. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected. Versions before 11.20 are unaffected. CVE-2012-0868 had fixed this class of problem, but version 11.20 reintroduced it.

Packages affected:

postgresql14 > 0-0 (version in image is 14.19-150200.5.61.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2025-38499 Severity: Important CVSS3 score: 8.4

Description: In the Linux kernel, the following vulnerability has been resolved:clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right usernsWhat we want is to verify there is that clone won't expose somethinghidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo"may be a result of MNT_LOCKED on a child, but it may also come fromlacking admin rights in the userns of the namespace mount belongs to.clone_private_mnt() checks the former, but not the latter.There's a number of rather confusing CAP_SYS_ADMIN checks in varioususerns during the mount, especially with the new mount API; they servedifferent purposes and in case of clone_private_mnt() they usually,but not always end up covering the missing check mentioned above.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2019-20330 Severity: Important CVSS3 score: 8.1

Description: FasterXML jackson-databind 2.x before 2.9.10.2 lacks certain net.sf.ehcache blocking.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
jackson-databind > 0-0 (version in image is 2.17.3-150200.3.23.1).

CVE-2024-47175 Severity: Important CVSS3 score: 8.1

Description: CUPS is a standards-based, open-source printing system, and `libppd` can be used for legacy PPD file support. The `libppd` function `ppdCreatePPDFromIPP2` does not sanitize IPP attributes when creating the PPD buffer. When used in combination with other functions such as `cfGetPrinterAttributes5`, can result in user controlled input and ultimately code execution via Foomatic. This vulnerability can be part of an exploit chain leading to remote code execution (RCE), as described in CVE-2024-47176.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
cups-config > 0-0 (version in image is 2.2.7-150000.3.72.1).

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

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

Packages affected:

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

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: allow exp not to be removed in nf_ct_find_expectationCurrently nf_conntrack_in() calling nf_ct_find_expectation() willremove the exp from the hash table. However, in some scenario, weexpect the exp not to be removed when the created ct will not beconfirmed, like in OVS and TC conntrack in the following patches.This patch allows exp not to be removed by setting IPS_CONFIRMEDin the status of the tmpl.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific socket configuration, which could allow a local user to crash the system or escalate their privileges on the system.

Packages affected:

kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2024-22029 Severity: Important CVSS3 score: 7.8

Description: Insecure permissions in the packaging of tomcat allow local users that win a race during package installation to escalate to root

Packages affected:

sle-module-web-scripting-release == 15.4 (version in image is 15.4-150400.55.1).
tomcat > 0-0 (version in image is 9.0.108-150200.91.1).

CVE-2024-44987 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent UAF in ip6_send_skb()syzbot reported an UAF in ip6_send_skb() [1]After ip6_local_out() has returned, we no longer can safelydereference rt, unless we hold rcu_read_lock().A similar issue has been fixed in commita688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")Another potential issue in ip6_finish_output2() is handled in aseparate patch.[1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f936bf79e79Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipc: fix to protect IPCS lookups using RCUsyzbot reported that it discovered a use-after-free vulnerability, [0][0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/idr_for_each() is protected by rwsem, but this is not enough. If it isnot protected by RCU read-critical region, when idr_for_each() callsradix_tree_node_free() through call_rcu() to free the radix_tree_nodestructure, the node will be freed immediately, and when reading the nextnode in radix_tree_for_each_slot(), the already freed memory may be read.Therefore, we need to add code to make sure that idr_for_each() isprotected within the RCU read-critical region when we call it inshm_destroy_orphaned().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Prevent overflow in size calculation for memdup_user()Number of apqn target list entries contained in 'nr_apqns' variable isdetermined by userspace via an ioctl call so the result of the product incalculation of size passed to memdup_user() may overflow.In this case the actual size of the allocated area and the valuedescribing it won't be in sync leading to various types of unpredictablebehaviour later.Use a proper memdup_array_user() helper which returns an error if anoverflow is detected. Note that it is different from when nr_apqns isinitially zero - that case is considered valid and should be handled insubsequent pkey_handler implementations.Found by Linux Verification Center (linuxtesting.org).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in crypt_message when using async cryptoThe CVE-2024-50047 fix removed asynchronous crypto handling fromcrypt_message(), assuming all crypto operations are synchronous.However, when hardware crypto accelerators are used, this can causeuse-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...);Hardware crypto modules often implement async AEAD operations forperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,the operation completes asynchronously. Without crypto_wait_req(),the function immediately frees the request buffer, leading to crasheswhen the driver later accesses the freed memory.This results in a use-after-free condition when the hardware cryptodriver later accesses the freed request structure, leading to kernelcrashes with NULL pointer dereferences.The issue occurs because crypto_alloc_aead() with mask=0 doesn'tguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC inthe mask, async implementations can be selected.Fix by restoring the async crypto handling:- DECLARE_CRYPTO_WAIT(wait) for completion tracking- aead_request_set_callback() for async completion notification- crypto_wait_req() to wait for operation completionThis ensures the request buffer isn't freed until the crypto operationcompletes, whether synchronous or asynchronous, while preserving theCVE-2024-50047 fix.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: do not bypass hid_hw_raw_requesthid_hw_raw_request() is actually useful to ensure the provided bufferand length are valid. Directly calling in the low level transport driverfunction bypassed those checks and allowed invalid paramto be used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: ensure the allocated report buffer can contain the reserved report IDWhen the report ID is not used, the low level transport drivers expectthe first byte to be 0. However, currently the allocated buffer notaccount for that extra byte, meaning that instead of having 8 guaranteedbytes for implement to be working, we only have 7.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget : fix use-after-free in composite_dev_cleanup()1. In func configfs_composite_bind() -> composite_os_desc_req_prepare():if kmalloc fails, the pointer cdev->os_desc_req will be freed but notset to NULL. Then it will return a failure to the upper-level function.2. in func configfs_composite_bind() -> composite_dev_cleanup():it will checks whether cdev->os_desc_req is NULL. If it is not NULL, itwill attempt to use it.This will lead to a use-after-free issue.BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0Read of size 8 at addr 0000004827837a00 by task init/1CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
tar > 0-0 (version in image is 1.34-150000.3.34.1).

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

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

Packages affected:

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

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

Description: There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libsqlite3-0 > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2017-18640 Severity: Important CVSS3 score: 7.5

Description: The Alias feature in SnakeYAML before 1.26 allows entity expansion during a load operation, a related issue to CVE-2003-1564.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
snakeyaml > 0-0 (version in image is 2.2-150200.3.15.1).

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

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

Packages affected:

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

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

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

Packages affected:

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

CVE-2020-36518 Severity: Important CVSS3 score: 7.5

Description: jackson-databind before 2.13.0 allows a Java StackOverflow exception and denial of service via a large depth of nested objects.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
jackson-databind > 0-0 (version in image is 2.17.3-150200.3.23.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

Description: When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request's memory resources were not reclaimed immediately. Instead, de-allocation was deferred to connection close. A client could send new requests and resets, keeping the connection busy and open and causing the memory footprint to keep on growing. On connection close, all resources were reclaimed, but the process might run out of memory before that.This was found by the reporter during testing of CVE-2023-44487 (HTTP/2 Rapid Reset Exploit) with their own test client. During "normal" HTTP/2 use, the probability to hit this bug is very low. The kept memory would not become noticeable before the connection closes or times out.Users are recommended to upgrade to version 2.4.58, which fixes the issue.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
apache2 > 0-0 (version in image is 2.4.51-150400.6.46.1).

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

Description: Arbitrary File Overwrite in Eclipse JGit <= 6.6.0In Eclipse JGit, all versions <= 6.6.0.202305301015-r, a symbolic link present in a specially crafted git repository can be used to write a file to locations outside the working tree when this repository is cloned with JGit to a case-insensitive filesystem, or when a checkout from a clone of such a repository is performed on a case-insensitive filesystem.This can happen on checkout (DirCacheCheckout), merge (ResolveMerger via its WorkingTreeUpdater), pull (PullCommand using merge), and when applying a patch (PatchApplier). This can be exploited for remote code execution (RCE), for instance if the file written outside the working tree is a git filter that gets executed on a subsequent git command.The issue occurs only on case-insensitive filesystems, like the default filesystems on Windows and macOS. The user performing the clone or checkout must have the rights to create symbolic links for the problem to occur, and symbolic links must be enabled in the git configuration.Setting git configuration option core.symlinks = false before checking out avoids the problem.The issue was fixed in Eclipse JGit version 6.6.1.202309021850-r and 6.7.0.202309050840-r, available via Maven Central https://repo1.maven.org/maven2/org/eclipse/jgit/ and repo.eclipse.org https://repo.eclipse.org/content/repositories/jgit-releases/ . A backport is available in 5.13.3 starting from 5.13.3.202401111512-r.The JGit maintainers would like to thank RyotaK for finding and reporting this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
jsch < 0.2.9-150200.11.10.1 (version in image is 0.1.55-150400.2.15).

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

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

Packages affected:

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

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

Description: SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
google-guest-agent > 0-0 (version in image is 20250506.01-150000.1.63.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().syzkaller reported a null-ptr-deref in sock_omalloc() while allocatinga CALIPSO option. [0]The NULL is of struct sock, which was fetched by sk_to_full_sk() incalipso_req_setattr().Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),reqsk->rsk_listener could be NULL when SYN Cookie is returned to itsclient, as hinted by the leading SYN Cookie log.Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookiefor CALIPSO. 3) is also no go as there have been many efforts to reduceatomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35("tcp/dccp: do not touch listener sk_refcnt under synflood").As of the blamed commit, SYN Cookie already did not need refcounting,and no one has stumbled on the bug for 9 years, so no CALIPSO user willcare about SYN Cookie.Let's return an error in calipso_req_setattr() and calipso_req_delattr()in the SYN Cookie case.This can be reproduced by [1] on Fedora and now connect() of nc times out.[0]:TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]RIP: 0010:sock_net include/net/sock.h:655 [inline]RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8bRSP: 0018:ffff88811af89038 EFLAGS: 00010216RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640eR10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0PKRU: 80000000Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netf---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sev: Evict cache lines during SNP memory validationAn SNP cache coherency vulnerability requires a cache line evictionmitigation when validating memory after a page state change to private.The specific mitigation is to touch the first and last byte of each 4Kpage that is being validated. There is no need to perform the mitigationwhen performing a page state change to shared and rescinding validation.CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bitthat, when set, indicates that the software mitigation for thisvulnerability is not needed.Implement the mitigation and invoke it when validating memory (making itprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNPguest is vulnerable.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Prevent VMA split of buffer mappingsThe perf mmap code is careful about mmap()'ing the user page with theringbuffer and additionally the auxiliary buffer, when the event supportsit. Once the first mapping is established, subsequent mapping have to usethe same offset and the same size in both cases. The reference counting forthe ringbuffer and the auxiliary buffer depends on this being correct.Though perf does not prevent that a related mapping is split via mmap(2),munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,which take reference counts, but then the subsequent perf_mmap_close()calls are not longer fulfilling the offset and size checks. This leads toreference count leaks.As perf already has the requirement for subsequent mappings to match theinitial mapping, the obvious consequence is that VMA splits, caused byresizing of a mapping or partial unmapping, have to be prevented.Implement the vm_operations_struct::may_split() callback and returnunconditionally -EINVAL.That ensures that the mapping offsets and sizes cannot be changed after thefact. Remapping to a different fixed address with the same size is stillpossible as it takes the references for the new mapping and drops those ofthe old mapping.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: Improper Resource Shutdown or Release vulnerability in Apache Tomcat made Tomcat vulnerable to the made you reset attack.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.9, from 10.1.0-M1 through 10.1.43 and from 9.0.0.M1 through 9.0.107. Older, EOL versions may also be affected.Users are recommended to upgrade to one of versions 11.0.10, 10.1.44 or 9.0.108 which fix the issue.

Packages affected:

tomcat > 0-0 (version in image is 9.0.108-150200.91.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

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

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
cups-config > 0-0 (version in image is 2.2.7-150000.3.72.1).

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

Description: 1. A cookie is set using the `secure` keyword for `https://target` 2. curl is redirected to or otherwise made to speak with `http://target` (same hostname, but using clear text HTTP) using the same cookie set 3. The same cookie name is set - but with just a slash as path (`path=\"/\",`). Since this site is not secure, the cookie *should* just be ignored.4. A bug in the path comparison logic makes curl read outside a heap buffer boundaryThe bug either causes a crash or it potentially makes the comparison come tothe wrong conclusion and lets the clear-text site override the contents of thesecure cookie, contrary to expectations and depending on the memory contentsimmediately following the single-byte allocation that holds the path.The presumed and correct behavior would be to plainly ignore the second set ofthe cookie since it was already set as secure on a secure host so overridingit on an insecure host should not be okay.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2024-20918 Severity: Important CVSS3 score: 7.4

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2024-20952 Severity: Important CVSS3 score: 7.4

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-PyJWT > 0-0 (version in image is 2.4.0-150200.3.8.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Always pass notifications when child class becomes emptyCertain classful qdiscs may invoke their classes' dequeue handler on anenqueue operation. This may unexpectedly empty the child qdisc and thusmake an in-flight class passive via qlen_notify(). Most qdiscs do notexpect such behaviour at this point in time and may re-activate theclass eventually anyways which will lead to a use-after-free.The referenced fix commit attempted to fix this behavior for the HFSCcase by moving the backlog accounting around, though this turned out tobe incomplete since the parent's parent may run into the issue too.The following reproducer demonstrates this use-after-free: tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888Since backlog accounting issues leading to a use-after-frees on staleclass pointers is a recurring pattern at this point, this patch takesa different approach. Instead of trying to fix the accounting, the patchensures that qdisc_tree_reduce_backlog always calls qlen_notify whenthe child qdisc is empty. This solves the problem because deletion ofqdiscs always involves a call to qdisc_reset() and / orqdisc_purge_queue() which ultimately resets its qlen to 0 thus causingthe following qdisc_tree_reduce_backlog() to report to the parent. Notethat this may call qlen_notify on passive classes multiple times. Thisis not a problem after the recent patch series that made all theclassful qdiscs qlen_notify() handlers idempotent.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

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

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktlsWhen sending plaintext data, we initially calculated the correspondingciphertext length. However, if we later reduced the plaintext data lengthvia socket policy, we failed to recalculate the ciphertext length.This results in transmitting buffers containing uninitialized data duringciphertext transmission.This causes uninitialized bytes to be appended after a complete"Application Data" packet, leading to errors on the receiving end whenparsing TLS record.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: No more self recoveryWhen a node withdraws and it turns out that it is the only node that hasthe filesystem mounted, gfs2 currently tries to replay the local journalto bring the filesystem back into a consistent state. Not only is thata very bad idea, it has also never worked because gfs2_recover_func()will refuse to do anything during a withdraw.However, before even getting to this point, gfs2_recover_func()dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free beforecommit 04133b607a78 ("gfs2: Prevent double iput for journal on error")and is a NULL pointer dereference since then.Simply get rid of self recovery to fix that.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: Fix use-after-free Read in usb_udc_uevent()The syzbot fuzzer found a race between uevent callbacks and gadgetdriver unregistration that can cause a use-after-free bug:---------------------------------------------------------------BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130drivers/usb/gadget/udc/core.c:1732Read of size 8 at addr ffff888078ce2050 by task udevd/2968CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google06/29/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424---------------------------------------------------------------The bug occurs because usb_udc_uevent() dereferences udc->driver butdoes so without acquiring the udc_lock mutex, which protects thisfield. If the gadget driver is unbound from the udc concurrently withuevent processing, the driver structure may be accessed after it hasbeen deallocated.To prevent the race, we make sure that the routine holds the mutexaround the racing accesses.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

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

CVE-2024-53164 Severity: Important CVSS3 score: 7.0

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58239 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:tls: stop recv() if initial process_rx_list gave us non-DATAIf we have a non-DATA record on the rx_list and another record of thesame type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATAJust check the record type and jump to the end in case process_rx_listdid some work.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mdiobus: Fix potential out-of-bounds read/write accessWhen using publicly available tools like 'mdio-tools' to read/write datafrom/to network interface and its PHY via mdiobus, there is no verification ofparameters passed to the ioctl and it accepts any mdio address.Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,but it is possible to pass higher value than that via ioctl.While read/write operation should generally fail in this case,mdiobus provides stats array, where wrong address may allow out-of-boundsread/write.Fix that by adding address verification before read/write operation.While this excludes this access from any statistics, it improves security ofread/write operation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix double free in delayed_freeThe double free could happen in the following path.exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double freeThis patch set ->vol_util as NULL after freeing it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix race condition on qfq_aggregateA race condition can occur when 'agg' is modified in qfq_change_agg(called during qfq_enqueue) while other threads access itconcurrently. For example, qfq_dump_class may trigger a NULLdereference, and qfq_delete_class may cause a use-after-free.This patch addresses the issue by:1. Moved qfq_destroy_class into the critical section.2. Added sch_tree_lock protection to qfq_dump_class andqfq_dump_class_stats.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Do not allow binding to VMADDR_PORT_ANYIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This cancause a use-after-free when a connection is made to the bound socket.The socket returned by accept() also has port VMADDR_PORT_ANY but is noton the list of unbound sockets. Binding it will result in an extrarefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keepthe binding until socket destruction).Modify the check in __vsock_bind_connectible() to also prevent bindingto VMADDR_PORT_ANY.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix a null pointer dereference in ice_copy_and_init_pkg()Add check for the return value of devm_kmemdup()to prevent potential null pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

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

Description: A vulnerability has been identified in the libarchive library, specifically within the archive_read_format_rar_seek_data() function. This flaw involves an integer overflow that can ultimately lead to a double-free condition. Exploiting a double-free vulnerability can result in memory corruption, enabling an attacker to execute arbitrary code or cause a denial-of-service condition.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libarchive13 > 0-0 (version in image is 3.5.1-150400.3.21.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

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

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
glibc > 0-0 (version in image is 2.31-150300.95.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

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

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

Packages affected:

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

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-idna > 0-0 (version in image is 2.6-150000.3.6.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).

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

Description: Unknown.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

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

Description: Jinja is an extensible templating engine. Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter 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 use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-Jinja2 > 0-0 (version in image is 2.10.1-150000.3.21.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
iputils > 0-0 (version in image is 20211215-150400.3.22.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libpcap1 > 0-0 (version in image is 1.10.1-150400.3.6.2).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeoutWhile the rhashtable set gc runs asynchronously, a race allows it tocollect elements from anonymous sets with timeouts while it is beingreleased from the commit path.Mingi Cho originally reported this issue in a different path in 6.1.xwith a pipapo set with low timeouts which is not possible upstream since7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for setelement timeout").Fix this by setting on the dead flag for anonymous sets to skip async gcin this case.According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead ontransaction abort"), Florian plans to accelerate abort path by releasingobjects via workqueue, therefore, this sets on the dead flag for abortpath too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

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

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

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

Packages affected:

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

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

Description: In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
postgresql-jdbc > 0-0 (version in image is 42.2.25-150400.3.12.1).

CVE-2024-24861 Severity: Moderate CVSS3 score: 6.3

Description: A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26988 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:init/main.c: Fix potential static_command_line memory overflowWe allocate memory of size 'xlen + strlen(boot_command_line) + 1' forstatic_command_line, but the strings copied into static_command_line areextra_command_line and command_line, rather than extra_command_line andboot_command_line.When strlen(command_line) > strlen(boot_command_line), static_command_linewill overflow.This patch just recovers strlen(command_line) which was miss-consolidatedwith strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: addchecks for the return value of memblock_alloc*()")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38659 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:enic: Validate length of nl attributes in enic_set_vf_portenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILEis of length PORT_PROFILE_MAX and that the nl attributesIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.These attributes are validated (in the function do_setlink in rtnetlink.c)using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILEas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY andIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validationusing the policy is for the max size of the attributes and not on exactsize so the length of these attributes might be less than the sizes thatenic_set_vf_port expects. This might cause an out of bandsread access in the memcpys of the data of theseattributes in enic_set_vf_port.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39508 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: Use set_bit() and test_bit() at worker->flagsUtilize set_bit() and test_bit() on worker->flags within io_uring/io-wqto address potential data races.The structure io_worker->flags may be accessed through various datapaths, leading to concurrency issues. When KCSAN is enabled, it revealsdata races occurring in io_worker_handle_work andio_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198)Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' ofgit://git.kernel.org/pub/scm/virt/kvm/kvm").These races involve writes and reads to the same memory location bydifferent tasks running on different CPUs. To mitigate this, refactorthe code to use atomic operations such as set_bit(), test_bit(), andclear_bit() instead of basic "and" and "or" operations. This ensuresthread-safe manipulation of worker flags.Also, move `create_index` to avoid holes in the structure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41020 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:filelock: Fix fcntl/close race recovery compat pathWhen I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably whenfcntl/close race is detected"), I missed that there are two copies of thecode I was patching: The normal version, and the version for 64-bit offsetson 32-bit kernels.Thanks to Greg KH for stumbling over this while doing the stablebackport...Apply exactly the same fix to the compat path for 32-bit kernels.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41044 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: reject claimed-as-LCP but actually malformed packetsSince 'ppp_async_encode()' assumes valid LCP packets (with codefrom 1 to 7 inclusive), add 'ppp_check_packet()' to ensure thatLCP packet has an actual body beyond PPP_LCP header bytes, andreject claimed-as-LCP but actually malformed data otherwise.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42084 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47408 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check smcd_v2_ext_offset when receiving proposal msgWhen receiving proposal msg in server, the field smcd_v2_ext_offset inproposal msg is from the remote client and can not be fully trusted.Once the value of smcd_v2_ext_offset exceed the max value, there hasthe chance to access wrong address, and crash may happen.This patch checks the value of smcd_v2_ext_offset before using it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49568 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msgWhen receiving proposal msg in server, the fields v2_ext_offset/eid_cnt/ism_gid_cnt in proposal msg are from the remote clientand can not be fully trusted. Especially the field v2_ext_offset,once exceed the max value, there has the chance to access wrongaddress, and crash may happen.This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cntbefore using them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49571 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50063 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tail call between progs attached to different hooksbpf progs can be attached to kernel functions, and the attached functionscan take different parameters or return different return values. Ifprog attached to one kernel function tail calls prog attached to anotherkernel function, the ctx access or return value verification could bebypassed.For example, if prog1 is attached to func1 which takes only 1 parameterand prog2 is attached to func2 which takes two parameters. Since verifierassumes the bpf ctx passed to prog2 is constructed based on func2'sprototype, verifier allows prog2 to access the second parameter fromthe bpf ctx passed to it. The problem is that verifier does not preventprog1 from passing its bpf ctx to prog2 via tail call. In this case,the bpf ctx passed to prog2 is constructed from func1 instead of func2,that is, the assumption for ctx access verification is bypassed.Another example, if BPF LSM prog1 is attached to hook file_alloc_security,and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifierknows the return value rules for these two hooks, e.g. it is legal forbpf_lsm_audit_rule_known to return positive number 1, and it is illegalfor file_alloc_security to return positive number. So verifier allowsprog2 to return positive number 1, but does not allow prog1 to returnpositive number. The problem is that verifier does not prevent prog1from calling prog2 via tail call. In this case, prog2's return value 1will be used as the return value for prog1's hook file_alloc_security.That is, the return value rule is bypassed.This patch adds restriction for tail call to prevent such bypasses.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50135 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix race condition between reset and nvme_dev_disable()nvme_dev_disable() modifies the dev->online_queues field, thereforenvme_pci_update_nr_queues() should avoid racing against it, otherwisewe could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]Fix the bug by locking the shutdown_lock mutex before usingdev->online_queues. Give up if nvme_dev_disable() is running or ifit has been executed already.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50142 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50278 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53088 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix race condition by adding filter's intermediate sync stateFix a race condition in the i40e driver that leads to MAC/VLAN filtersbecoming corrupted and leaking. Address the issue that occurs underheavy load when multiple threads are concurrently modifying MAC/VLANfilters by setting mac and port VLAN.1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan().2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac().3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption.Reproduction steps:1. Spawn multiple VFs.2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host.3. Observe errors in dmesg:"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX".Exact code for stable reproduction Intel can't open-source now.The fix involves implementing a new intermediate filter state,I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.These filters cannot be deleted from the hash list directly butmust be removed using the full process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53147 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix out-of-bounds access of directory entriesIn the case of the directory size is greater than or equal tothe cluster size, if start_clu becomes an EOF cluster(an invalidcluster) due to file system corruption, then the directory entrywhere ei->hint_femp.eidx hint is outside the directory, resultingin an out-of-bounds access, which may cause further file systemcorruption.This commit adds a check for start_clu, if it is an invalid cluster,the file or directory will be treated as empty.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57900 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: update channel list in reg notifier instead reg workerCurrently when ath11k gets a new channel list, it will be processedaccording to the following steps:1. update new channel list to cfg80211 and queue reg_work.2. cfg80211 handles new channel list during reg_work.3. update cfg80211's handled channel list to firmware byath11k_reg_update_chan_list().But ath11k will immediately execute step 3 after reg_work is justqueued. Since step 2 is asynchronous, cfg80211 may not have completedhandling the new channel list, which may leading to an out-of-boundswrite error:BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_listCall Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0Should ensure step 2 is completely done before executing step 3. ThusWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,cfg80211 will notify ath11k after step 2 is done.So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 willnotify ath11k after step 2 is done. At this time, there will be noKASAN bug during the execution of the step 3.[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Avoid race in open_cached_dir with lease breaksA pre-existing valid cfid returned from find_or_create_cached_dir mightrace with a lease break, meaning open_cached_dir doesn't consider itvalid, and thinks it's newly-constructed. This leaks a dentry referenceif the allocation occurs before the queued lease break work runs.Avoid the race by extending holding the cfid_list_lock acrossfind_or_create_cached_dir and when the result is checked.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add locking for bcm_op runtime updatesThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames viahrtimer. The content and also the length of the sequence can be changedresp reduced at runtime where the 'currframe' counter is then set to zero.Although this appeared to be a safe operation the updates of 'currframe'can be triggered from user space and hrtimer context in bcm_can_tx().Anderson Nascimento created a proof of concept that triggered a KASANslab-out-of-bounds read access which can be prevented with a spin_lock_bh.At the rework of bcm_can_tx() the 'count' variable has been moved intothe protected section as this variable can be modified from both contextstoo.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:virtio: break and reset virtio devices on device_shutdown()Hongyu reported a hang on kexec in a VM. QEMU reported invalid memoryaccesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ...It was traced down to virtio-console. Kexec works fine if virtio-consoleis not in use.The issue is that virtio-console continues to write to the MMIO even afterunderlying virtio-pci device is reset.Additionally, Eric noticed that IOMMUs are reset before devices, ifdevices are not reset on shutdown they continue to poke at guest memoryand get errors from the IOMMU. Some devices get wedged then.The problem can be solved by breaking all virtio devices on virtiobus shutdown, then resetting them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful.2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]---To fix this, check for !dma_mapping_error() before callingdma_unmap_single() on the "theend_iv" path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a race between renames and directory loggingWe have a race between a rename and directory inode logging that if ithappens and we crash/power fail before the rename completes, the next timethe filesystem is mounted, the log replay code will end up deleting thefile that was being renamed.This is best explained following a step by step analysis of an interleavingof steps that lead into this situation.Consider the initial conditions:1) We are at transaction N;2) We have directories A and B created in a past transaction (< N);3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N);4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N).The steps leading to a file loss are the following and for all of them weare under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree;10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost.The issue wouldn't happen if task B synced the log only after task Acalled btrfs_log_new_name(), which would update the log with the new namefor inode Y ("A/bar").Fix this by pinning the log root during renames before removing the olddirectory entry, and unpinning af---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-38469 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2023-38471 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2023-38472 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2023-52491 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_runIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0 CPU1mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_workmtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //useIf we close the file descriptor, which will call mtk_jpeg_release,it will have a similar sequence.Fix this bug by starting timeout worker only if started jpegdec workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-6915 Severity: Moderate CVSS3 score: 6.2

Description: A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38428 Severity: Moderate CVSS3 score: 6.2

Description: url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
wget > 0-0 (version in image is 1.20.3-150000.3.29.1).

CVE-2024-4317 Severity: Moderate CVSS3 score: 6.2

Description: Missing authorization in PostgreSQL built-in views pg_stats_ext and pg_stats_ext_exprs allows an unprivileged database user to read most common values and other statistics from CREATE STATISTICS commands of other users. The most common values may reveal column values the eavesdropper could not otherwise read or results of functions they cannot execute. Installing an unaffected version only fixes fresh PostgreSQL installations, namely those that are created with the initdb utility after installing that version. Current PostgreSQL installations will remain vulnerable until they follow the instructions in the release notes. Within major versions 14-16, minor versions before PostgreSQL 16.3, 15.7, and 14.12 are affected. Versions before PostgreSQL 14 are unaffected.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
postgresql14 > 0-0 (version in image is 14.19-150200.5.61.1).

CVE-2024-45490 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2024-45491 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2024-45492 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Tear down vGIC on failed vCPU creationIf kvm_arch_vcpu_create() fails to share the vCPU page with thehypervisor, we propagate the error back to the ioctl but leave thevGIC vCPU data initialised. Note only does this leak the correspondingmemory when the vCPU is destroyed but it can also lead to use-after-freeif the redistributor device handling tries to walk into the vCPU.Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that thevGIC vCPU structures are destroyed on error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
perl > 0-0 (version in image is 5.26.1-150300.17.20.1).

CVE-2022-48980 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()The SJA1105 family has 45 L2 policing table entries(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure butaccounting for the difference in port count (5 in SJA1105 vs 10 inSJA1110) does not fully explain the difference. Rather, the SJA1110 alsohas L2 ingress policers for multicast traffic. If a packet is classifiedas multicast, it will be processed by the policer index 99 + SRCPORT.The sja1105_init_l2_policing() function initializes all L2 policers suchthat they don't interfere with normal packet reception by default. To havea common code between SJA1105 and SJA1110, the index of the multicastpolicer for the port is calculated because it's an index that is out ofbounds for SJA1105 but in bounds for SJA1110, and a bounds check isperformed.The code fails to do the proper thing when determining what to do with themulticast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"index will be equal to 45, which is also equal totable->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passesthrough the check. But at the same time, SJA1105 doesn't have multicastpolicers. So the code programs the SHARINDX field of an out-of-boundselement in the L2 Policing table of the static config.The comparison between index 45 and 45 entries should have determined thecode to not access this policer index on SJA1105, since its memory wasn'teven allocated.With enough bad luck, the out-of-bounds write could even overwrite othervalid kernel data, but in this case, the issue was detected using KASAN.Kernel log:sja1105 spi5.0: Probed switch chip: SJA1105Q==================================================================BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8...Workqueue: events_unbound deferred_probe_work_funcCall trace:...sja1105_setup+0x1cbc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...Allocated by task 8:...sja1105_setup+0x1bcc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: An out-of-bounds read vulnerability was found in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0607 Severity: Moderate CVSS3 score: 6.1

Description: A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-10524 Severity: Moderate CVSS3 score: 6.1

Description: Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
wget > 0-0 (version in image is 1.20.3-150000.3.29.1).

CVE-2024-26635 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:llc: Drop support for ETH_P_TR_802_2.syzbot reported an uninit-value bug below. [0]llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2(0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)llc_conn_handler() initialises local variables {saddr,daddr}.macbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passesthem to __llc_lookup().However, the initialisation is done only when skb->protocol ishtons(ETH_P_802_2), otherwise, __llc_lookup_established() and__llc_lookup_listener() will read garbage.The missing initialisation existed prior to commit 211ed865108e("net: delete all instances of special processing for token ring").It removed the part to kick out the token ring stuff but forgot toclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let's remove llc_tr_packet_type and complete the deprecation.[0]:BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bLocal variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26641 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].Call pskb_inet_may_pull() to fix this, and initialize ipv6hvariable after this call as it can change skb->head.[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-34064 Severity: Moderate CVSS3 score: 6.1

Description: Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-Jinja2 > 0-0 (version in image is 2.10.1-150000.3.21.1).

CVE-2024-36025 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()The app_reply->elem[] array is allocated earlier in this function and ithas app_req.num_ports elements. Thus this > comparison needs to be >= toprevent memory corruption.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36960 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix invalid reads in fence signaled eventsCorrectly set the length of the drm_event to the size of the structurethat's actually used.The length of the drm_event was set to the parent structure instead ofto the drm_vmw_event_fence which is supposed to be read. drm_readuses the length parameter to copy the event to the user space thusresuling in oob reads.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37354 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix crash on racing fsync and size-extending write into preallocWe have been seeing crashes on duplicate keys inbtrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)So we're logging a changed extent from fsync, which is splitting anextent in the log tree. But this split part already exists in the tree,triggering the BUG().This is the state of the log tree at the time of the crash, dumped withdrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ...So the real problem happened earlier: notice that items 4 (4k-12k) and 5(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size anditem 5 starts at i_size.Here is the state of ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38552 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential index out of bounds in color transformation functionFixes index out of bounds issue in the color transformation function.The issue could occur when the index 'i' exceeds the number of transferfunction points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds, an error message islogged and the function returns false to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38594 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: move the EST lock to struct stmmac_privReinitialize the whole EST structure would also reset the mutexlock which is embedded in the EST structure, and then triggerthe following warning. To address this, move the lock to structstmmac_priv. We also need to reacquire the mutex lock when doingthis initialization.DEBUG_LOCKS_WARN_ON(lock->magic != lock)WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39487 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()In function bond_option_arp_ip_targets_set(), if newval->string is anempty string, newval->string+1 will point to the byte after thestring, causing an out-of-bound read.BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b---[ end trace ]---Fix it by adding a check of string length before using it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39505 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/komeda: check for error-valued pointerkomeda_pipeline_get_state() may return an error-valued pointer, thuscheck the pointer for negative or null value before dereferencing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42096 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86: stop playing stack games in profile_pc()The 'profile_pc()' function is used for timer-based profiling, whichisn't really all that relevant any more to begin with, but it also endsup making assumptions based on the stack layout that aren't necessarilyvalid.Basically, the code tries to account the time spent in spinlocks to thecaller rather than the spinlock, and while I support that as a concept,it's not worth the code complexity or the KASAN warnings when no seriousprofiling is done using timers anyway these days.And the code really does depend on stack layout that is only true in thesimplest of cases. We've lost the comment at some point (I think whenthe 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF.which explains why it just blindly loads a word or two straight off thestack pointer and then takes a minimal look at the values to just checkif they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addressesbut that basic stack layout assumption assumes that there isn't any lockdebugging etc going on that would complicate the code and cause a stackframe.It causes KASAN unhappiness reported for years by syzkaller [1] andothers [2].With no real practical reason for this any more, just remove the code.Just for historical interest, here's some background commits relating tothis code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc")but the basics of this thing actually goes back to before the git tree.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42104 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: add missing check for inode numbers on directory entriesSyzbot reported that mounting and unmounting a specific pattern ofcorrupted nilfs2 filesystem images causes a use-after-free of metadatafile inodes, which triggers a kernel bug in lru_add_fn().As Jan Kara pointed out, this is because the link count of a metadata filegets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),tries to delete that inode (ifile inode in this case).The inconsistency occurs because directories containing the inode numbersof these metadata files that should not be visible in the namespace areread without checking.Fix this issue by treating the inode numbers of these internal files aserrors in the sanity check helper when reading directory folios/pages.Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layeranalysis.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42105 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix inode number range checksPatch series "nilfs2: fix potential issues related to reserved inodes".This series fixes one use-after-free issue reported by syzbot, caused bynilfs2's internal inode being exposed in the namespace on a corruptedfilesystem, and a couple of flaws that cause problems if the startingnumber of non-reserved inodes written in the on-disk super block isintentionally (or corruptly) changed from its default value. This patch (of 3):In the current implementation of nilfs2, "nilfs->ns_first_ino", whichgives the first non-reserved inode number, is read from the superblock,but its lower limit is not checked.As a result, if a number that overlaps with the inode number range ofreserved inodes such as the root directory or metadata files is set in thesuper block parameter, the inode number test macros (NILFS_MDT_INODE andNILFS_VALID_INODE) will not function properly.In addition, these test macros use left bit-shift calculations using withthe inode number as the shift count via the BIT macro, but the result of ashift calculation that exceeds the bit width of an integer is undefined inthe C specification, so if "ns_first_ino" is set to a large value otherthan the default value NILFS_USER_INO (=11), the macros may potentiallymalfunction depending on the environment.Fix these issues by checking the lower bound of "nilfs->ns_first_ino" andby preventing bit shifts equal to or greater than the NILFS_USER_INOconstant in the inode number test macros.Also, change the type of "ns_first_ino" from signed integer to unsignedinteger to avoid the need for type casting in comparisons such as thelower bound check introduced this time.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42259 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Fix Virtual Memory mapping boundaries calculationCalculating the size of the mapped area as the lesser valuebetween the requested size and the actual size does not considerthe partial mapping offset. This can cause page fault access.Fix the calculation of the starting and ending addresses, thetotal size is now deduced from the difference between the end andstart addresses.Additionally, the calculations have been rewritten in a clearerand more understandable form.[Joonas: Add Requires: tag]Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53052 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rw: fix missing NOWAIT check for O_DIRECT start writeWhen io_uring starts a write, it'll call kiocb_start_write() to bump thesuper block rwsem, preventing any freezes from happening while thatwrite is in-flight. The freeze side will grab that rwsem for writing,excluding any new writers from happening and waiting for existing writesto finish. But io_uring unconditionally uses kiocb_start_write(), whichwill block if someone is currently attempting to freeze the mount point.This causes a deadlock where freeze is waiting for previous writes tocomplete, but the previous writes cannot complete, as the task that issupposed to complete them is blocked waiting on starting a new write.This results in the following stuck trace showing that dependency withthe write blocked starting a new write:task:fio state:D stack:0 pid:886 tgid:886 ppid:876Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963with the attempting freezer stuck trying to grab the rwsem:task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt ablocking grab of the super block rwsem if it isn't set. For normal issuewhere IOCB_NOWAIT would always be set, this returns -EAGAIN which willhave io_uring core issue a blocking attempt of the write. That will inturn also get completions run, ensuring forward progress.Since freezing requires CAP_SYS_ADMIN in the first place, this isn'tsomething that can be triggered by a regular user.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53099 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check validity of link->type in bpf_link_show_fdinfo()If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessingbpf_link_type_strs[link->type] may result in an out-of-bounds access.To spot such missed invocations early in the future, checking thevalidity of link->type in bpf_link_show_fdinfo() and emitting a warningwhen such invocations are missed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53138 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ("nfs: add support for large folios")).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53151 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: Address an integer overflowDan Carpenter reports:> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data> structure") from Jun 22, 2020 (linux-next), leads to the following> Smatch static checker warning:>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)> 489 {> 490 u32 segcount;> 491 __be32 *p;> 492> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))> ^^^^^^^^>> 494 return false;> 495> 496 /* A bogus segcount causes this buffer overflow check to fail. */> 497 p = xdr_inline_decode(&rctxt->rc_stream,> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));>>> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will> have an integer overflow and some those values will be accepted by> xdr_inline_decode().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53155 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53158 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()This loop is supposed to break if the frequency returned fromclk_round_rate() is the same as on the previous iteration. However,that check doesn't make sense on the first iteration through the loop.It leads to reading before the start of these->clk_perf_tbl[] array.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53161 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/bluefield: Fix potential integer overflowThe 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idxleft-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as32-bits wide the left-shift operation truncates the upper 16 bits ofinformation during the calculation of the SMC argument.The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent anypotential integer overflow, i.e. loss of data from upper 16 bits.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53213 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: Fix double free issue with interrupt buffer allocationIn lan78xx_probe(), the buffer `buf` was being freed twice: onceimplicitly through `usb_free_urb(dev->urb_intr)` with the`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This causeda double free issue.To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls tosimplify the initialization sequence and removed the redundant`kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuringit is correctly managed by `usb_fill_int_urb()` and freed by`usb_free_urb()` as intended.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56754 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Fix the pointer passed to caam_qi_shutdown()The type of the last parameter given to devm_add_action_or_reset() is"struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to"struct device *".Pass the correct parameter to devm_add_action_or_reset() so that theresources are released as expected.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56769 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57899 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58096 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor modeath11k_hal_srng_* should be used with srng->lock to protect srng data.For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),they use ath11k_hal_srng_* for many times but never call srng->lock.So when running (full) monitor mode, warning will occur:RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319So add srng->lock for them to avoid such warnings.Inorder to fetch the srng->lock, should change srng's definition from'void' to 'struct hal_srng'. And initialize them elsewhere to preventone line of code from being too long. This is consistent with other ringprocess functions, such as ath11k_dp_process_rx().Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: Fix KMSAN uninit-value warning with bpfSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by theppp driver not initializing a 2-byte header when using socket filter.The following code can generate a PPP filter BPF program:'''struct bpf_program fp;pcap_t *handle;handle = pcap_open_dead(DLT_PPP_PPPD, 65535);pcap_compile(handle, &fp, "ip and outbound", 0, 0);bpf_dump(&fp, 1);'''Its output is:'''(000) ldh [2](001) jeq #0x21 jt 2 jf 5(002) ldb [0](003) jeq #0x1 jt 4 jf 5(004) ret #65535(005) ret #0'''Wen can find similar code at the following link:https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680The maintainer of this code repository is also the original maintainerof the ppp driver.As you can see the BPF program skips 2 bytes of data and then reads the'Protocol' field to determine if it's an IP packet. Then it read the firstbyte of the first 2 bytes to determine the direction.The issue is that only the first byte indicating direction is initializedin current ppp driver code while the second byte is not initialized.For normal BPF programs generated by libpcap, uninitialized data won't beused, so it's not a problem. However, for carefully crafted BPF programs,such as those generated by syzkaller [2], which start reading from offset0, the uninitialized data will be used and caught by KMSAN.[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing closetimeo mount optionUser-provided mount parameter closetimeo of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the 'function_graph' tracer to the'timerlat' tracer, s_start only calls graph_trace_close of the'function_graph' tracer to free 'iter->private', but does not setit to NULL. This provides an opportunity for 'event->funcs->trace()'to use an invalid 'iter->private'.To fix this issue, set 'iter->private' to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary'iter->private = NULL' during each 'cat trace' when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Don't expose hw_counters outside of init net namespaceCommit 467f432a521a ("RDMA/core: Split port and device counter sysfsattributes") accidentally almost exposed hw counters to non-init netnamespaces. It didn't expose them fully, as an attempt to read any ofthose counters leads to a crash like this one:[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028[42021.814463] #PF: supervisor read access in kernel mode[42021.819549] #PF: error_code(0x0000) - not-present page[42021.824636] PGD 0 P4D 0[42021.827145] Oops: 0000 [#1] SMP PTI[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX[42021.841697] Hardware name: XXX[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core][42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[42021.949324] Call Trace:[42021.951756] [42021.953842] [] ? show_regs+0x64/0x70[42021.959030] [] ? __die+0x78/0xc0[42021.963874] [] ? page_fault_oops+0x2b5/0x3b0[42021.969749] [] ? exc_page_fault+0x1a2/0x3c0[42021.975549] [] ? asm_exc_page_fault+0x26/0x30[42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core][42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core][42021.995438] [] dev_attr_show+0x1e/0x50[42022.000803] [] sysfs_kf_seq_show+0x81/0xe0[42022.006508] [] seq_read_iter+0xf4/0x410[42022.011954] [] vfs_read+0x16e/0x2f0[42022.017058] [] ksys_read+0x6e/0xe0[42022.022073] [] do_syscall_64+0x6a/0xa0[42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*The panic occurs because of casting the device pointer into anib_device pointer using container_of() in hw_stat_device_show() iswrong and leads to a memory corruption.However the real problem is that hw counters should never been exposedoutside of the non-init net namespace.Fix this by saving the index of the corresponding attribute group(it might be 1 or 2 depending on the presence of driver-specificattributes) and zeroing the pointer to hw_counters group for compatdevices during the initialization.With this fix applied hw_counters are not available in a non-initnet namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[pabeni@redhat.com: fixed subj typo]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:padata: do not leak refcount in reorder_workA recent patch that addressed a UAF introduced a reference count leak:the parallel_data refcount is incremented unconditionally, regardlessof the return value of queue_work(). If the work item is already queued,the incremented refcount is never decremented.Fix this by checking the return value of queue_work() and decrementingthe refcount when necessary.Resolves:Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lzo - Fix compression buffer overrunUnlike the decompression code, the compression code in LZO neverchecked for output overruns. It instead assumes that the calleralways provides enough buffer space, disregarding the buffer lengthprovided by the caller.Add a safe compression interface that checks for the end of bufferbefore each write. Use the safe interface in crypto/lzo.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: clear the dst when changing skb protocolA not-so-careful NAT46 BPF program can crash the kernelif it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10)The output interface has a 4->6 program attached at ingress.We try to loop the multicast skb back to the sending socket.Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdrand changes skb->protocol to v6. We enter ip6_rcv_core whichtries to use skb_dst(). But the dst is still an IPv4 one leftafter IPv4 mcast output.Clear the dst in all BPF helpers which change the protocol.Try to preserve metadata dsts, those may carry non-routingmetadata.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: reject invalid perturb periodGerrard Tai reported that SFQ perturb_period has no range check yet,and this can be used to trigger a race condition fixed in a separate patch.We want to make sure ctl->perturb_period * HZ will not overflowand is positive.tc qd add dev lo root sfq perturb -10 # negative value : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 1000000000 # too big : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 2000000 # acceptable valuetc -s -d qd sh dev loqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell_rbu: Fix list usagePass the correct list head to list_for_each_entry*() when looping throughthe packet list.Without this patch, reading the packet data via sysfs will show the dataincorrectly (because it starts at the wrong packet), and clearing thepacket list will result in a NULL pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix use-after-free of work objects after cm_id destructionThe commit 59c68ac31e15 ("iw_cm: free cm_id resources on the lastderef") simplified cm_id resource management by freeing cm_id once allreferences to the cm_id were removed. The references are removed eitherupon completion of iw_cm event handlers or when the application destroysthe cm_id. This commit introduced the use-after-free condition wherecm_id_private object could still be in use by event handler works duringthe destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix ause-after-free related to destroying CM IDs") addressed this use-after-free by flushing all pending works at the cm_id destruction.However, still another use-after-free possibility remained. It happenswith the work objects allocated for each cm_id_priv withinalloc_work_entries() during cm_id creation, and subsequently freed indealloc_work_entries() once all references to the cm_id are removed.If the cm_id's last reference is decremented in the event handler work,the work object for the work itself gets removed, and causes the use-after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30This BUG is reproducible by repeating the blktests test case nvme/061for the rdma transport and the siw driver.To avoid the use-after-free of cm_id_private work objects, ensure thatthe last reference to the cm_id is decremented not in the event handlerworks, but in the cm_id destruction context. For that purpose, mo---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: inline: fix len overflow in ext4_prepare_inline_dataWhen running the following code on an ext4 filesystem with inline_datafeature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL);That happens because write_begin will succeed as whenext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + lenwill be truncated, leading to ext4_prepare_inline_data parameter to be 6instead of 0x10000000006.Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);at ext4_write_inline_data.Fix it by using a loff_t type for the len parameter inext4_prepare_inline_data instead of an unsigned int.[ 44.545164] ------------[ cut here ]------------[ 44.545530] kernel BUG at fs/ext4/inline.c:240![ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0[ 44.546523] PKRU: 55555554[ 44.546523] Call Trace:[ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0[ 44.546523] generic_perform_write+0x17e/0x270[ 44.546523] ext4_buffered_write_iter+0xc8/0x170[ 44.546523] vfs_write+0x2be/0x3e0[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0[ 44.546523] do_syscall_64+0x6a/0xf0[ 44.546523] ? __wake_up+0x89/0xb0[ 44.546523] ? xas_find+0x72/0x1c0[ 44.546523] ? next_uptodate_folio+0x317/0x330[ 44.546523] ? set_pte_range+0x1a6/0x270[ 44.546523] ? filemap_map_pages+0x6ee/0x840[ 44.546523] ? ext4_setattr+0x2fa/0x750[ 44.546523] ? do_pte_missing+0x128/0xf70[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0[ 44.546523] ? ___pte_offset_map+0x19/0x100[ 44.546523] ? handle_mm_fault+0x721/0xa10[ 44.546523] ? do_user_addr_fault+0x197/0x730[ 44.546523] ? do_syscall_64+0x76/0xf0[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 44.546523] RIP: 0033:0x7f42999c6687[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()In snd_usb_get_audioformat_uac3(), the length value returned fromsnd_usb_ctl_msg() is used directly for memory allocation withoutvalidation. This length is controlled by the USB device.The allocated buffer is cast to a uac3_cluster_header_descriptorand its fields are accessed without verifying that the bufferis large enough. If the device returns a smaller than expectedlength, this leads to an out-of-bounds read.Add a length check to ensure the buffer is large enough foruac3_cluster_header_descriptor.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:seg6: Fix validation of nexthop addressesThe kernel currently validates that the length of the provided nexthopaddress does not exceed the specified length. This can lead to thekernel reading uninitialized memory if user space provided a shorterlength than the specified one.Fix by validating that the provided length exactly matches the specifiedone.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Prevent attempts to reclaim poisoned pagesTL;DR: SGX page reclaim touches the page to copy its contents tosecondary storage. SGX instructions do not gracefully handle machinechecks. Despite this, the existing SGX code will try to reclaim pagesthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.The longer story:Pages used by an enclave only get epc_page->poison set inarch_memory_failure() but they currently stay on sgx_active_page_list untilsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.epc_page->poison is not checked in the reclaimer logic meaning that, if otherconditions are met, an attempt will be made to reclaim an EPC page that waspoisoned. This is bad because 1. we don't want that page to end up addedto another enclave and 2. it is likely to cause one core to shut downand the kernel to panic.Specifically, reclaiming uses microcode operations including "EWB" whichaccesses the EPC page contents to encrypt and write them out to non-SGXmemory. Those operations cannot handle MCEs in their accesses other thanby putting the executing core into a special shutdown state (affectingboth threads with HT.) The kernel will subsequently panic on theremaining cores seeing the core didn't enter MCE handler(s) in time.Call sgx_unmark_page_reclaimable() to remove the affected EPC page fromsgx_active_page_list on memory error to stop it being considered forreclaiming.Testing epc_page->poison in sgx_reclaim_pages() would also work but I assumeit's better to add code in the less likely paths.The affected EPC page is not added to &node->sgx_poison_page_list untillater in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd.Membership on other lists doesn't change to avoid changing any of thelists' semantics except for sgx_active_page_list. There's a "TBD" commentin arch_memory_failure() about pre-emptive actions, the goal here is notto address everything that it may imply.This also doesn't completely close the time window when a memory errornotification will be fatal (for a not previously poisoned EPC page) --the MCE can happen after sgx_reclaim_pages() has selected its candidatesor even *inside* a microcode operation (actually easy to trigger due tothe amount of time spent in them.)The spinlock in sgx_unmark_page_reclaimable() is safe becausememory_failure() runs in process context and no spinlocks are held,explicitly noted in a mm/memory-failure.c comment.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/vmci: Clear the vmci transport packet properly when initializing itIn vmci_transport_packet_init memset the vmci_transport_packet beforepopulating the fields to avoid any uninitialised data being left in thestructure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: check msg length in SMBUS block readFor SMBUS block read, do not continue to read if the message lengthpassed from the device is '0' or greater than the maximum allowed bytes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix uaf in nbd_genl_connect() error pathThere is a use-after-free issue in nbd:block nbd6: Receive control failed (result -104)block nbd6: shutting down sockets==================================================================BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: nbd6-recv recv_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() does not properly stop the device on certainerror paths after nbd_start_device() has been called. This causesthe error path to put nbd->config while recv_work continue to usethe config after putting it, leading to use-after-free in recv_work.This patch moves nbd_start_device() after the backend file creation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: aio_iiro_16: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl812: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iio: common: st_sensors: Fix use of uninitialize device structsThroughout the various probe functions &indio_dev->dev is used before itis initialized. This caused a kernel panic in st_sensors_power_enable()when the call to devm_regulator_bulk_get_enable() fails and then callsdev_err_probe() with the uninitialized device.This seems to only cause a panic with dev_err_probe(), dev_err(),dev_warn() and dev_info() don't seem to cause a panic, but are fixedas well.The issue is reported and traced here: [1]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

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

Description: A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2023-52612 Severity: Important CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: scomp - fix req->dst buffer overflowThe req->dst buffer size should be checked before copying from thescomp_scratch->dst to avoid req->dst buffer overflow problem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36910 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Don't free decrypted memoryIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus device UIO driver could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the gpadlto decide whether to free the memory.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41038 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headersCheck that all fields of a V2 algorithm header fit into the availablefirmware data buffer.The wmfw V2 format introduced variable-length strings in the algorithmblock header. This means the overall header length is variable, and theposition of most fields varies depending on the length of the stringfields. Each field must be checked to ensure that it does not overflowthe firmware data buffer.As this ia bugfix patch, the fixes avoid making any significant change tothe existing code. This makes it easier to review and less likely tointroduce new bugs.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47742 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware_loader: Block path traversalMost firmware names are hardcoded strings, or are constructed from fairlyconstrained format strings where the dynamic parts are just some hexnumbers or such.However, there are a couple codepaths in the kernel where firmware filenames contain string components that are passed through from a device orsemi-privileged userspace; the ones I could find (not counting interfacesthat require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.)Fix it by rejecting any firmware names containing ".." path components.For what it's worth, I went looking and haven't found any USB devicedrivers that use the firmware loader dangerously.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56566 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: Avoid list corruption when removing a slab from the full listBoot with slub_debug=UFPZ.If allocated object failed in alloc_consistency_checks, all objects ofthe slab will be marked as used, and then the slab will be removed fromthe partial list.When an object belonging to the slab got freed later, the remove_full()function is called. Because the slab is neither on the partial list noron the full list, it eventually lead to a list corruption (actually alist poison being detected).So we need to mark and isolate the slab page with metadata corruption,do not put it back in circulation.Because the debug caches avoid all the fastpaths, reusing the frozen bitto mark slab page with metadata corruption seems to be fine.[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100)[ 4277.387023] ------------[ cut here ]------------[ 4277.387880] kernel BUG at lib/list_debug.c:56![ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs][ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4277.410000] PKRU: 55555554[ 4277.410645] Call Trace:[ 4277.411234] [ 4277.411777] ? die+0x32/0x80[ 4277.412439] ? do_trap+0xd6/0x100[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.414158] ? do_error_trap+0x6a/0x90[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.415915] ? exc_invalid_op+0x4c/0x60[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.420410] free_to_partial_list+0x515/0x5e0[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs][ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs][ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs][ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs][ 4277.428567] xfs_inactive+0x22d/0x290 [xfs][ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.430479] process_one_work+0x171/0x340[ 4277.431227] worker_thread+0x277/0x390[ 4277.431962] ? __pfx_worker_thread+0x10/0x10[ 4277.432752] kthread+0xf0/0x120[ 4277.433382] ? __pfx_kthread+0x10/0x10[ 4277.434134] ret_from_fork+0x2d/0x50[ 4277.434837] ? __pfx_kthread+0x10/0x10[ 4277.435566] ret_from_fork_asm+0x1b/0x30[ 4277.436280]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix MMIO write access to an invalid page in i40e_clear_hwWhen the device sends a specific input, an integer underflow can occur, leadingto MMIO write access to an invalid page.Prevent the integer underflow by changing the type of related variables.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
screen > 0-0 (version in image is 4.6.2-150000.5.8.1).

CVE-2023-48795 Severity: Important CVSS3 score: 5.9

Description: The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
jsch < 0.2.15-150200.11.13.1 (version in image is 0.1.55-150400.2.15).

CVE-2020-25659 Severity: Moderate CVSS3 score: 5.9

Description: python-cryptography 3.2 is vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-cryptography > 0-0 (version in image is 3.3.2-150400.26.1).

CVE-2023-46589 Severity: Moderate CVSS3 score: 5.9

Description: Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82 and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.Older, EOL versions may also be affected.Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue.

Packages affected:

sle-module-web-scripting-release == 15.4 (version in image is 15.4-150400.55.1).
tomcat > 0-0 (version in image is 9.0.108-150200.91.1).

CVE-2023-5981 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2023-7008 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in systemd-resolved. This issue may allow systemd-resolved to accept records of DNSSEC-signed domains even when they have no signature, allowing man-in-the-middles (or the upstream DNS resolver) to manipulate records.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libsystemd0 > 0-0 (version in image is 249.17-150400.8.49.2).

CVE-2024-0553 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2024-0567 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2024-20919 Severity: Moderate CVSS3 score: 5.9

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2024-20921 Severity: Moderate CVSS3 score: 5.9

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2024-20926 Severity: Moderate CVSS3 score: 5.9

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2024-47081 Severity: Moderate CVSS3 score: 5.9

Description: Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-requests > 0-0 (version in image is 2.25.1-150300.3.18.1).

CVE-2024-50602 Severity: Moderate CVSS3 score: 5.9

Description: An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2024-56431 Severity: Moderate CVSS3 score: 5.9

Description: oc_huff_tree_unpack in huffdec.c in libtheora in Theora through 1.0 7180717 has an invalid negative left shift. NOTE: this is disputed by third parties because there is no evidence of a security impact, e.g., an application would not crash.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libmozjs-60 > 0-0 (version in image is 60.9.0-150200.6.3.1).

CVE-2024-56703 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix soft lockups in fib6_select_path under high next hop churnSoft lockups have been observed on a cluster of Linux-based edge routerslocated in a highly dynamic environment. Using the `bird` service, theserouters continuously update BGP-advertised routes due to frequentlychanging nexthop destinations, while also managing significant IPv6traffic. The lockups occur during the traversal of the multipathcircular linked-list in the `fib6_select_path` function, particularlywhile iterating through the siblings in the list. The issue typicallyarises when the nodes of the linked list are unexpectedly deletedconcurrently on a different core-indicated by their 'next' and'previous' elements pointing back to the node itself and their referencecount dropping to zero. This results in an infinite loop, leading to asoft lockup that triggers a system panic via the watchdog timer.Apply RCU primitives in the problematic code sections to resolve theissue. Where necessary, update the references to fib6_siblings toannotate or use the RCU APIs.Include a test script that reproduces the issue. The scriptperiodically updates the routing table while generating a heavy loadof outgoing IPv6 traffic through multiple iperf3 clients. Itconsistently induces infinite soft lockups within a couple of minutes.Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d-- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b512 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f4713 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d014 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd9627415 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd9647416 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd9661517 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b319 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b920 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc1800024 [ffffbd13003d3db8] net_rx_action at ffffffff8dc1858125 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e926 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe4727 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a3028 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa6430 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56718 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: protect link down work from execute after lgr freedlink down work may be scheduled before lgr freed but executeafter lgr freed, which may result in crash. So it is need tohold a reference before shedule link down work, and put thereference after work executed or canceled.The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21959 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbagecollection confirm race"), `cpu` and `jiffies32` were introduced tothe struct nf_conncount_tuple.The commit made nf_conncount_add() initialize `conn->cpu` and`conn->jiffies32` when allocating the struct.In contrast, count_tree() was not changed to initialize them.By commit 34848d5c896e ("netfilter: nf_conncount: Split insert andtraversal"), count_tree() was split and the relevant allocationcode now resides in insert_tree().Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22063 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 socketsWhen calling netlbl_conn_setattr(), addr->sa_family is usedto determine the function behavior. If sk is an IPv4 socket,but the connect function is called with an IPv6 address,the function calipso_sock_setattr() is triggered.Inside this function, the following code is executed:sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;Since sk is an IPv4 socket, pinet6 is NULL, leading to anull pointer dereference.This patch fixes the issue by checking if inet6_sk(sk)returns a NULL pointer before accessing pinet6.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-3360 Severity: Moderate CVSS3 score: 5.9

Description: A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2025-3576 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2025-38035 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: don't restore null sk_state_changequeue->state_change is set as part of nvmet_tcp_set_queue_sock(), but ifthe TCP connection isn't established when nvmet_tcp_set_queue_sock() iscalled then queue->state_change isn't set and sock->sk->sk_state_changeisn't replaced.As such we don't need to restore sock->sk->sk_state_change ifqueue->state_change is NULL.This avoids NULL pointer dereferences such as this:[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 286.467147][ C0] RIP: 0010:0x0[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400[ 286.475453][ C0] Call Trace:[ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60[ 286.478174][ C0] ? __build_skb_around+0x234/0x330[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30[ 286.482769][ C0] ? ktime_get+0x66/0x150[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10[ 286.486917][ C0] ? lock_release+0x217/0x2c0[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack][ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420[ 286.494268][ C0] ip_local_deliver+0x168/0x430[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20[ 286.496806][ C0] ? lock_release+0x217/0x2c0[ 286.497414][ C0] ip_rcv+0x455/0x6e0[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10[ ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-52434 Severity: Moderate CVSS3 score: 5.9

Description: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Tomcat when using the APR/Native connector. This was particularly noticeable with client initiated closes of HTTP/2 connections.This issue affects Apache Tomcat: from 9.0.0.M1 through 9.0.106.The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Other, older, EOL versions may also be affected.Users are recommended to upgrade to version 9.0.107, which fixes the issue.

Packages affected:

tomcat > 0-0 (version in image is 9.0.108-150200.91.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2025-52520 Severity: Moderate CVSS3 score: 5.9

Description: For some unlikely configurations of multipart upload, an Integer Overflow vulnerability in Apache Tomcat could lead to a DoS via bypassing of size limits.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106.The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Other, older, EOL versions may also be affected.Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.

Packages affected:

tomcat > 0-0 (version in image is 9.0.108-150200.91.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2025-7962 Severity: Moderate CVSS3 score: 5.9

Description: In Jakarta Mail 2.0.2 it is possible to preform a SMTP Injection by utilizing the \r and \n UTF-8 characters to separate different messages.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
javamail > 0-0 (version in image is 1.6.2-150200.3.7.1).

CVE-2022-49939 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix UAF of ref->proc caused by race conditionA transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment thereference for a node. In this case, the target proc normally releasesthe failed reference upon close as expected. However, if the target isdying in parallel the call will race with binder_deferred_release(), sothe target could have released all of its references by now leaving thecleanup of the new failed reference unhandled.The transaction then ends and the target proc gets released making theref->proc now a dangling pointer. Later on, ref->node is closed and weattempt to take spin_lock(&ref->proc->inner_lock), which leads to theuse-after-free bug reported below. Let's fix this by cleaning up thefailed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi->poll_ownernon atomically. The ->poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46675 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Prevent USB core invalid event buffer address accessThis commit addresses an issue where the USB core could access aninvalid event buffer address during runtime suspend, potentially causingSMMU faults and other memory issues in Exynos platforms. The problemarises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.To prevent this hardware quirk on Exynos platforms, this commit ensuresthat the event buffer address is not cleared by software when the USBcore is active during runtime suspend by checking its status beforeclearing the buffer address.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53680 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free in hdcpThe HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connectorobjects without incrementing the kref reference counts. When using aUSB-C dock, and the dock is unplugged, the correspondingamdgpu_dm_connector objects are freed, creating dangling pointers in theHDCP code. When the dock is plugged back, the dangling pointers aredereferenced, resulting in a slab-use-after-free:[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024[ 66.776186] Workqueue: events event_property_validate [amdgpu][ 66.776494] Call Trace:[ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0[ 66.776504] print_report+0x175/0x555[ 66.776507] ? __virt_addr_valid+0x243/0x450[ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0[ 66.776515] kasan_report+0xeb/0x1c0[ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777121] __asan_report_load4_noabort+0x14/0x20[ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777342] ? __lock_acquire+0x6b40/0x6b40[ 66.777347] ? enable_assr+0x250/0x250 [amdgpu][ 66.777571] process_one_work+0x86b/0x1510[ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0[ 66.777578] ? assign_work+0x16b/0x280[ 66.777580] ? lock_is_held_type+0xa3/0x130[ 66.777583] worker_thread+0x5c0/0xfa0[ 66.777587] ? process_one_work+0x1510/0x1510[ 66.777588] kthread+0x3a2/0x840[ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777594] ? trace_hardirqs_on+0x4f/0x60[ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60[ 66.777599] ? calculate_sigpending+0x77/0xa0[ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777605] ret_from_fork+0x40/0x90[ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777609] ret_from_fork_asm+0x11/0x20[ 66.777614] [ 66.777643] Allocated by task 10:[ 66.777646] kasan_save_stack+0x39/0x60[ 66.777649] kasan_save_track+0x14/0x40[ 66.777652] kasan_save_alloc_info+0x37/0x50[ 66.777655] __kasan_kmalloc+0xbb/0xc0[ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0[ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu][ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper][ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper][ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper][ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper][ 66.777917] process_one_work+0x86b/0x1510[ 66.777919] worker_thread+0x5c0/0xfa0[ 66.777922] kthread+0x3a2/0x840[ 66.777925] ret_from_fork+0x40/0x90[ 66.777927] ret_from_fork_asm+0x11/0x20[ 66.777932] Freed by task 1713:[ 66.777935] kasan_save_stack+0x39/0x60[ 66.777938] kasan_save_track+0x14/0x40[ 66.777940] kasan_save_free_info+0x3b/0x60[ 66.777944] __kasan_slab_free+0x52/0x70[ 66.777946] kfree+0x13f/0x4b0[ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu][ 66.778179] drm_connector_free+0x7d/0xb0[ 66.778184] drm_mode_object_put.part.0+0xee/0x160[ 66.778188] drm_mode_object_put+0x37/0x50[ 66.778191] drm_atomic_state_default_clear+0x220/0xd60[ 66.778194] __drm_atomic_state_free+0x16e/0x2a0[ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0[ 66.778200] drm_ioctl_kernel+0x17a/0x310[ 66.778203] drm_ioctl+0x584/0xd10[ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu][ 66.778375] __x64_sys_ioctl+0x139/0x1a0[ 66.778378] x64_sys_call+0xee7/0xfb0[ 66.778381] ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Add missing lockingRecent kernels complain about a missing lock in k3-udma.c when the lockvalidator is enabled:[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28[ 4.144867] Hardware name: pp-v12 (DT)[ 4.148648] Workqueue: events udma_check_tx_completion[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.160834] pc : udma_start.isra.0+0x34/0x238[ 4.165227] lr : udma_start.isra.0+0x30/0x238[ 4.169618] sp : ffffffc083cabcf0[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000[ 4.244986] Call trace:[ 4.247463] udma_start.isra.0+0x34/0x238[ 4.251509] udma_check_tx_completion+0xd0/0xdc[ 4.256076] process_one_work+0x244/0x3fc[ 4.260129] process_scheduled_works+0x6c/0x74[ 4.264610] worker_thread+0x150/0x1dc[ 4.268398] kthread+0xd8/0xe8[ 4.271492] ret_from_fork+0x10/0x20[ 4.275107] irq event stamp: 220[ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50[ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50[ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc[ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28[ 4.311559] ---[ end trace 0000000000000000 ]---This commit adds the missing locking.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookieThe IOMMU translation for MSI message addresses has been a 2-step process,separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.This has an inherent lifetime problem for the pointer stored in the cookiethat must remain valid between the two steps. However, there is no lockingat the irq layer that helps protect the lifetime. Today, this works underthe assumption that the iommu domain is not changed while MSI interruptsbeing programmed. This is true for normal DMA API users within the kernel,as the iommu domain is attached before the driver is probed and cannot bechanged while a driver is attached.Classic VFIO type1 also prevented changing the iommu domain while VFIO wasrunning as it does not support changing the "container" after starting up.However, iommufd has improved this so that the iommu domain can be changedduring VFIO operation. This potentially allows userspace to directly raceVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) andVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).This potentially causes both the cookie pointer and the unlocked call toiommu_get_domain_for_dev() on the MSI translation path to become UAFs.Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVAaddress is already known during iommu_dma_prepare_msi() and cannot change.Thus, it can simply be stored as an integer in the MSI descriptor.The other UAF related to iommu_get_domain_for_dev() will be addressed inpatch "iommu: Make iommu_dma_prepare_msi() into a generic operation" byusing the IOMMU group mutex.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Protect mgmt_pending list with its own lockThis uses a mutex to protect from concurrent access of mgmt_pendinglist which can cause crashes like:==================================================================BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: validate AG parameters in dbMount() to prevent crashesValidate db_agheight, db_agwidth, and db_agstart in dbMount to catchcorrupted metadata early and avoid undefined behavior in dbAllocAG.Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:- agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0.- agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0.- agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9shift exponent -335544310 is negativeCPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check return result of sb_min_blocksizeSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.Syzkaller forks multiple processes which after mounting the Squashfsfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in theprocess of mounting a Squashfs filesystem on /dev/loop0, the failureoccurs. When this happens the following code in squashfs_fill_super()fails.----msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);msblk->devblksize_log2 = ffz(~msblk->devblksize);----sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2is set to 64.This subsequently causes theUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36shift exponent 64 is too large for 64-bit type 'u64' (aka'unsigned long long')This commit adds a check for a 0 return by sb_min_blocksize().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: uart: Set tty->disc_data only in success pathSetting tty->disc_data before opening the NCI device means we need toclean it up on error paths. This also opens some short window if devicestarts sending data, even before NCIUARTSETDRIVER IOCTL succeeded(broken hardware?). Close the window by exposing tty->disc_data only onthe success path, when opening of the NCI device and try_module_get()succeeds.The code differs in error path in one aspect: tty->disc_data won't beever assigned thus NULL-ified. This however should not be relevantdifference, because of "tty->disc_data=NULL" in nci_uart_tty_open().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_conn_close().syzbot reported a null-ptr-deref in tipc_conn_close() during netnsdismantle. [0]tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and callstipc_conn_close() for each tipc_conn.The problem is that tipc_conn_close() is called after releasing theIDR lock.At the same time, there might be tipc_conn_recv_work() running and itcould call tipc_conn_close() for the same tipc_conn and release itslast ->kref.Once we release the IDR lock in tipc_topsrv_stop(), there is noguarantee that the tipc_conn is alive.Let's hold the ref before releasing the lock and put the ref aftertipc_conn_close() in tipc_topsrv_stop().[0]:BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00)The buggy address belongs to the page:page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0flags: 0xfff00000000100(slab)raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-21546 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike "sg_write_same --ndob" we will crash in target_core_iblock/file'sexecute_write_same handlers when we go to access the se_cmd->t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don't support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-34324 Severity: Moderate CVSS3 score: 5.7

Description: Closing of an event channel in the Linux kernel can result in a deadlock.This happens when the close is being performed in parallel to an unrelatedXen console action and the handling of a Xen console interrupt in anunprivileged guest.The closing of an event channel is e.g. triggered by removal of aparavirtual device on the other side. As this action will cause consolemessages to be issued on the other side quite often, the chance oftriggering the deadlock is not neglectable.Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernelon Arm doesn't use queued-RW-locks, which are required to trigger theissue (on Arm32 a waiting writer doesn't block further readers to getthe lock).

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2023-52593 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'should check the return value before examining skb data. So convertthe latter to return an appropriate error code and propagate it toreturn from 'wfx_start_ap()' as well. Compile tested only.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38565 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: enable proper endpoint verificationSyzkaller reports [1] hitting a warning about an endpoint in usenot having an expected type to it.Fix the issue by checking for the existence of all properendpoints with their according types intact.Sadly, this patch has not been tested on real hardware.[1] Syzkaller report:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504...Call Trace: ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56590 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-28956 Severity: Moderate CVSS3 score: 5.6

Description: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35875 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:x86/coco: Require seeding RNG with RDRAND on CoCo systemsThere are few uses of CoCo that don't rely on working cryptography andhence a working RNG. Unfortunately, the CoCo threat model means that theVM host cannot be trusted and may actively work against guests toextract secrets or manipulate computation. Since a malicious host canmodify or observe nearly all inputs to guests, the only remaining sourceof entropy for CoCo guests is RDRAND.If RDRAND is broken -- due to CPU hardware fault -- the RNG as a wholeis meant to gracefully continue on gathering entropy from other sources,but since there aren't other sources on CoCo, this is catastrophic.This is mostly a concern at boot time when initially seeding the RNG, asafter that the consequences of a broken RDRAND are much moretheoretical.So, try at boot to seed the RNG using 256 bits of RDRAND output. If thisfails, panic(). This will also trigger if the system is booted withoutRDRAND, as RDRAND is essential for a safe CoCo boot.Add this deliberately to be "just a CoCo x86 driver feature" and notpart of the RNG itself. Many device drivers and platforms have somedesire to contribute something to the RNG, and add_device_randomness()is specifically meant for this purpose.Any driver can call it with seed data of any quality, or even garbagequality, and it can only possibly make the quality of the RNG better orhave no effect, but can never make it worse.Rather than trying to build something into the core of the RNG, considerthe particular CoCo issue just a CoCo issue, and therefore separate itall out into driver (well, arch/platform) code. [ bp: Massage commit message. ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36965 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: mediatek: Make sure IPI buffer fits in L2TCMThe IPI buffer location is read from the firmware that we load to theSystem Companion Processor, and it's not granted that both the SRAM(L2TCM) size that is defined in the devicetree node is large enoughfor that, and while this is especially true for multi-core SCP, it'sstill useful to check on single-core variants as well.Failing to perform this check may make this driver perform R/Woperations out of the L2TCM boundary, resulting (at best) in akernel panic.To fix that, check that the IPI buffer fits, otherwise return afailure and refuse to boot the relevant SCP core (or the SCP atall, if this is single core).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44974 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-32414 Severity: Moderate CVSS3 score: 5.6

Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2025-38422 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devicesMaximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kband 64 Kb respectively. Adjust max size definitions and return correctEEPROM length based on device. Also prevent out-of-bound read/write.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-55158 Severity: Moderate CVSS3 score: 5.6

Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2020-13631 Severity: Moderate CVSS3 score: 5.5

Description: SQLite before 3.32.0 allows a virtual table to be renamed to the name of one of its shadow tables, related to alter.c and build.c.

Packages affected:

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

CVE-2021-43859 Severity: Moderate CVSS3 score: 5.5

Description: XStream is an open source java library to serialize objects to XML and back again. Versions prior to 1.4.19 may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. XStream 1.4.19 monitors and accumulates the time it takes to add elements to collections and throws an exception if a set threshold is exceeded. Users are advised to upgrade as soon as possible. Users unable to upgrade may set the NO_REFERENCE mode to prevent recursion. See GHSA-rmr5-cpv2-vgjf for further details on a workaround if an upgrade is not possible.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xstream > 0-0 (version in image is 1.4.21-150200.3.28.1).

CVE-2021-47214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlb, userfaultfd: fix reservation restore on userfaultfd errorCurrently in the is_continue case in hugetlb_mcopy_atomic_pte(), if webail out using "goto out_release_unlock;" in the cases where idx >=size, or !huge_pte_none(), the code will detect that new_pagecache_page== false, and so call restore_reserve_on_error(). In this case I seerestore_reserve_on_error() delete the reservation, and the followingcall to remove_inode_hugepages() will increment h->resv_hugepagescausing a 100% reproducible leak.We should treat the is_continue case similar to adding a page into thepagecache and set new_pagecache_page to true, to indicate that there isno reservation to restore on the error path, and we need not callrestore_reserve_on_error(). Rename new_pagecache_page topage_in_pagecache to make that clear.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47432 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/generic-radix-tree.c: Don't overflow in peek()When we started spreading new inode numbers throughout most of the 64bit inode space, that triggered some corner case bugs, in particularsome integer overflows related to the radix tree code. Oops.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47512 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: prevent dismantle issueFor some reason, fq_pie_destroy() did not copyworking code from pie_destroy() and other qdiscs,thus causing elusive bug.Before calling del_timer_sync(&q->adapt_timer),we need to ensure timer will not rearm itself.rcu: INFO: rcu_preempt self-detected stall on CPUrcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579 (t=10501 jiffies g=13085 q=3989)NMI backtrace for cpu 0CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline] check_cpu_stall kernel/rcu/tree_stall.h:711 [inline] rcu_pending kernel/rcu/tree.c:3878 [inline] rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597 update_process_times+0x16d/0x200 kernel/time/timer.c:1785 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428 __run_hrtimer kernel/time/hrtimer.c:1685 [inline] __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638RIP: 0010:write_comp_data kernel/kcov.c:221 [inline]RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47515 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:seg6: fix the iif in the IPv6 socket control blockWhen an IPv4 packet is received, the ip_rcv_core(...) sets the receivinginterface index into the IPv4 socket control block (v5.16-rc4,net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif;If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRHheader, the seg6_do_srh_encap(...) performs the required encapsulation.In this case, the seg6_do_srh_encap function clears the IPv6 socket controlblock (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clearIP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).Since the IPv6 socket control block and the IPv4 socket control block sharethe same memory area (skb->cb), the receiving interface index info is lost(IP6CB(skb)->iif is set to zero).As a side effect, that condition triggers a NULL pointer dereference ifcommit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orignetdev") is applied.To fix that issue, we set the IP6CB(skb)->iif with the index of thereceiving interface once again.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sit: do not call ipip6_dev_free() from sit_init_net()ipip6_dev_free is sit dev->priv_destructor, already calledby register_netdevice() if something goes wrong.Alternative would be to make ipip6_dev_free() robust againstmultiple invocations, but other drivers do not implement thisstrategy.syzbot reported:dst_release underflowWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173Modules linked in:CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2cR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ipv6/sit.c:1414 [inline] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075 __do_sys_unshare kernel/fork.c:3146 [inline] __se_sys_unshare kernel/fork.c:3144 [inline] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f66c882ce99Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47590 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix deadlock in __mptcp_push_pending()__mptcp_push_pending() may call mptcp_flush_join_list() with subflowsocket lock held. If such call hits mptcp_sockopt_sync_all() thensubsequently __mptcp_sockopt_sync() could try to lock the subflowsocket for itself, causing a deadlock.sysrq: Show Blocked Statetask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000Call Trace: __schedule+0x2d6/0x10c0 ? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20 ? _raw_spin_lock_irqsave+0x26/0x50 schedule+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160 ? do_wait_intr_irq+0xa0/0xa0 ? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f9ba546c2d0RSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8 Fix the issue by using __mptcp_flush_join_list() instead of plainmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested byFlorian. The sockopt sync will be deferred to the workqueue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47591 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: remove tcp ulp setsockopt supportTCP_ULP setsockopt cannot be used for mptcp because its alreadyused internally to plumb subflow (tcp) sockets to the mptcp layer.syzbot managed to trigger a crash for mptcp connections that arein fallback mode:KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline][..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638Remove support for TCP_ULP setsockopt.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47593 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: clear 'kern' flag from fallback socketsThe mptcp ULP extension relies on sk->sk_sock_kern being set correctly:It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); fromworking for plain tcp sockets (any userspace-exposed socket).But in case of fallback, accept() can return a plain tcp sk.In such case, sk is still tagged as 'kernel' and setsockopt will work.This will crash the kernel, The subflow extension has a NULL ctx->connmptcp socket:BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0Call Trace: tcp_data_ready+0xf8/0x370 [..]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: never allow the PM to close a listener subflowCurrently, when deleting an endpoint the netlink PM treversesall the local MPTCP sockets, regardless of their status.If an MPTCP listener socket is bound to the IP matching thedelete endpoint, the listener TCP socket will be closed.That is unexpected, the PM should only affect data subflows.Additionally, syzbot was able to trigger a NULL ptr dereferencedue to the above:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ffRSP: 0018:ffffc90001f2f818 EFLAGS: 00010016RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0Call Trace: lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket.c:1864 [inline] __se_sys_accept net/socket.c:1861 [inline] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f177cd8b8e9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002bRAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340cR13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000 Fix the issue explicitly skipping MPTCP socket in TCP_LISTENstatus.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47599 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: use latest_dev in btrfs_show_devnameThe test case btrfs/238 reports the warning below: WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs] CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: btrfs_show_devname+0x108/0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 invoke_syscall+0x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x198/0x19cReason:While btrfs_prepare_sprout() moves the fs_devices::devices intofs_devices::seed_list, the btrfs_show_devname() searches for the devicesand found none, leading to the warning as in above.Fix:latest_dev is updated according to the changes to the device list.That means we could use the latest_dev->name to show the device name in/proc/self/mounts, the pointer will be always valid as it's assignedbefore the device is deleted from the list in remove or replace.The RCU protection is sufficient as the device structure is freed aftersynchronization.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netlink: af_netlink: Prevent empty skb by adding a check on len.Adding a check on len parameter to avoid empty skb. This prevents adivision error in netem_enqueue function which is caused when skb->len=0and skb->data_len=0 in the randomized corruption step as shown below.skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);Crash Report:[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family0 port 6081 - 0[ 343.216110] netem: version 1.3[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.11.0-2.el7 04/01/2014[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem][ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ffff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f74 f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:0000000000000000[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:ffff88800f8eda40[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:ffffffff94fb8445[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:0000000000000000[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:0000000000000020[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)knlGS:0000000000000000[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:00000000000006e0[ 343.250076] Call Trace:[ 343.250423] [ 343.250713] ? memcpy+0x4d/0x60[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem][ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem][ 343.253102] ? stack_trace_save+0x87/0xb0[ 343.253655] ? filter_irq_stacks+0xb0/0xb0[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem][ 343.254837] ? __kasan_check_write+0x14/0x20[ 343.255418] ? _raw_spin_lock+0x88/0xd6[ 343.255953] dev_qdisc_enqueue+0x50/0x180[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090[ 343.257083] ? netdev_core_pick_tx+0x300/0x300[ 343.257690] ? check_kcov_mode+0x10/0x40[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30[ 343.259529] ? setup_object.isra.71+0x23/0x90[ 343.260121] ? new_slab+0x26e/0x4b0[ 343.260609] ? kasan_poison+0x3a/0x50[ 343.261118] ? kasan_unpoison+0x28/0x50[ 343.261637] ? __kasan_slab_alloc+0x71/0x90[ 343.262214] ? memcpy+0x4d/0x60[ 343.262674] ? write_comp_data+0x2f/0x90[ 343.263209] ? __kasan_check_write+0x14/0x20[ 343.263802] ? __skb_clone+0x5d6/0x840[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.264958] dev_queue_xmit+0x1c/0x20[ 343.265470] netlink_deliver_tap+0x652/0x9c0[ 343.266067] netlink_unicast+0x5a0/0x7f0[ 343.266608] ? netlink_attachskb+0x860/0x860[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.267820] ? write_comp_data+0x2f/0x90[ 343.268367] netlink_sendmsg+0x922/0xe80[ 343.268899] ? netlink_unicast+0x7f0/0x7f0[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.270099] ? write_comp_data+0x2f/0x90[ 343.270644] ? netlink_unicast+0x7f0/0x7f0[ 343.271210] sock_sendmsg+0x155/0x190[ 343.271721] ____sys_sendmsg+0x75f/0x8f0[ 343.272262] ? kernel_sendmsg+0x60/0x60[ 343.272788] ? write_comp_data+0x2f/0x90[ 343.273332] ? write_comp_data+0x2f/0x90[ 343.273869] ___sys_sendmsg+0x10f/0x190[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80[ 343.274984] ? slab_post_alloc_hook+0x70/0x230[ 343.275597] ? futex_wait_setup+0x240/0x240[ 343.276175] ? security_file_alloc+0x3e/0x170[ 343.276779] ? write_comp_d---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48639 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix possible refcount leak in tc_new_tfilter()tfilter_put need to be called to put the refount got by tp->ops->get toavoid possible refcount leak when chain->tmplt_ops != NULL andchain->tmplt_ops != tp->ops.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix NULL deref in bond_rr_gen_slave_idFix a NULL dereference of the struct bonding.rr_tx_counter member becauseif a bond is initially created with an initial mode != zero (Round Robin)the memory required for the counter is never created and when the mode ischanged there is never any attempt to verify the memory is allocated uponswitching modes.This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48644 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: avoid disabling offload when it was never enabledIn an incredibly strange API design decision, qdisc->destroy() getscalled even if qdisc->init() never succeeded, not exclusively sincecommit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"),but apparently also earlier (in the case of qdisc_create_dflt()).The taprio qdisc does not fully acknowledge this when it attempts fulloffload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID intaprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGSparsed from netlink (in taprio_change(), tail called from taprio_init()).But in taprio_destroy(), we call taprio_disable_offload(), and thisdetermines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags).But looking at the implementation of FULL_OFFLOAD_IS_ENABLED()(a bitwise check of bit 1 in q->flags), it is invalid to call this macroon q->flags when it contains TAPRIO_FLAGS_INVALID, because that is setto U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true onan invalid set of flags.As a result, it is possible to crash the kernel if user space forces anerror between setting q->flags = TAPRIO_FLAGS_INVALID, and the callingof taprio_enable_offload(). This is because drivers do not expect theoffload to be disabled when it was never enabled.The error that we force here is to attach taprio as a non-root qdisc,but instead as child of an mqprio root qdisc:$ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0$ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAIUnable to handle kernel paging request at virtual address fffffffffffffff8[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPCall trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2cFix this by keeping track of the operations we made, and undo theoffload only if we actually did it.I've added "bool offloaded" inside a 4 byte hole between "int clockid"and "atomic64_t picos_per_byte". Now the first cache line looks likebelow:$ pahole -C taprio_sched net/sched/sch_taprio.ostruct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sfc/siena: fix null pointer dereference in efx_hard_start_xmitLike in previous patch for sfc, prevent potential (but unlikely) NULLpointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()invocations to the global workqueue to avoid a problem relatedwith deactivate_slab()/__free_slab() being called from an IRQ contexton PREEMPT_RT kernels.When the flush_all_cpu_locked() function is called from a task contextit may happen that a workqueue with WQ_MEM_RECLAIM bit set ends upflushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]Fix this bug by creating a workqueue for the flush operation withthe WQ_MEM_RECLAIM bit set.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix a use-after-freeThere are two .exit_cmd_priv implementations. Both implementations useresources associated with the SCSI host. Make sure that these resources arestill available when .exit_cmd_priv is called by waiting insidescsi_remove_host() until the tag set has been freed.This commit fixes the following use-after-free:==================================================================BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]Read of size 8 at addr ffff888100337000 by task multipathd/16727Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix potential memleak in papr_get_attr()`buf` is allocated in papr_get_attr(), and krealloc() of `buf`could fail. We need to free the original `buf` in the case of failure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48716 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd938x: fix incorrect used of portidMixer controls have the channel id in mixer->reg, which is not sameas port id. port id should be derived from chan_info array.So fix this. Without this, its possible that we could corruptstruct wcd938x_sdw_priv by accessing port_map array out of rangewith channel id instead of port id.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48742 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()While looking at one unrelated syzbot bug, I found the replay logicin __rtnl_newlink() to potentially trigger use-after-free.It is better to clear master_dev and m_ops inside the loop,in case we have to replay it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48755 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instructionThe illegal instruction turned out to be 'ldbrx' emitted forBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use ofthe same and implement an alternative approach for older processors.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix information leakage in /proc/net/ptypeIn one net namespace, after creating a packet socket without bindingit to a device, users in other net namespaces can observe the new`packet_type` added by this packet socket by reading `/proc/net/ptype`file. This is minor information leakage as packet socket isnamespace aware.Add a net pointer in `packet_type` to keep the net namespace ofof corresponding packet socket. In `ptype_seq_show`, this net pointermust be checked when it is not NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.Mirrors the logic for dcn30. Cue lots of WARNs and somekernel panics without this fix.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()task_pt_regs() can return NULL on powerpc for kernel threads. This isthen used in __bpf_get_stack() to check for user mode, resulting in akernel oops. Guard against this by checking return value oftask_pt_regs() before trying to obtain the call chain.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: lgdt3306a: Add a check against null-pointer-defThe driver should check whether the client provides the platform_data.The following log reveals it:[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414[ 29.612820] Call Trace:[ 29.613030] [ 29.613201] dump_stack_lvl+0x56/0x6f[ 29.613496] ? kmemdup+0x30/0x40[ 29.613754] print_report.cold+0x494/0x6b7[ 29.614082] ? kmemdup+0x30/0x40[ 29.614340] kasan_report+0x8a/0x190[ 29.614628] ? kmemdup+0x30/0x40[ 29.614888] kasan_check_range+0x14d/0x1d0[ 29.615213] memcpy+0x20/0x60[ 29.615454] kmemdup+0x30/0x40[ 29.615700] lgdt3306a_probe+0x52/0x310[ 29.616339] i2c_device_probe+0x951/0xa90

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix a memleak when uncloning an skb dst and its metadataWhen uncloning an skb dst and its associated metadata, a newdst+metadata is allocated and later replaces the old one in the skb.This is helpful to have a non-shared dst+metadata attached to a specificskb.The issue is the uncloned dst+metadata is initialized with a refcount of1, which is increased to 2 before attaching it to the skb. Whentun_dst_unclone returns, the dst+metadata is only referenced from asingle place (the skb) while its refcount is 2. Its refcount will neverdrop to 0 (when the skb is consumed), leading to a memory leak.Fix this by removing the call to dst_hold in tun_dst_unclone, as thedst+metadata refcount is already 1.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure pathip[6]mr_free_table() can only be called under RTNL lock.RTNL: assertion failed at net/core/dev.c (10367)WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Modules linked in:CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 eeRSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfeceRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f4ab89f9059Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: hdmi: Unregister codec device on unbindOn bind we will register the HDMI codec device but we don't unregisterit on unbind, leading to a device leakage. Unregister our device atunbind.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix kernel-infoleak for SCTP socketssyzbot reported a kernel infoleak [1] of 4 bytes.After analysis, it turned out r->idiag_expires is not initializedif inet_sctp_diag_fill() calls inet_diag_msg_common_fill()Make sure to clear idiag_timer/idiag_retrans/idiag_expiresand let inet_diag_msg_sctpasoc_fill() fill them again if needed.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeBytes 68-71 of 2508 are uninitializedMemory access of size 2508 starts at ffff888114f9b000Data copied to user address 00007f7fe09ff2e0CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix kernel panic when enabling bearerWhen enabling a bearer on a node, a kernel panic is observed:[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]...[ 4.520030] Call Trace:[ 4.520689] [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc][ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc][ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc][ 4.525292] tipc_rcv+0x5da/0x730 [tipc][ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc][ 4.528737] __netif_receive_skb_list_core+0x20b/0x260[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0[ 4.531450] ? dev_gro_receive+0x4c2/0x680[ 4.532512] napi_complete_done+0x6f/0x180[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]...The node in question is receiving activate messages in anotherthread after changing bearer status to allow message sending/receiving in current thread: thread 1 | thread 2 -------- | -------- |tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } |Monitoring pointer in thread 2 is dereferenced before monitoring datais allocated in thread 1. This causes kernel panic.This commit fixes it by allocating the monitoring data before enablingthe bearer to receive messages.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not start relocation until in progress drops are doneWe hit a bug with a recovering relocation on mount for one of our filesystems in production. I reproduced this locally by injecting errorsinto snapshot delete with balance running at the same time. Thispresented as an error while looking up an extent item WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50 ? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Normally snapshot deletion and relocation are excluded from running atthe same time by the fs_info->cleaner_mutex. However if we had apending balance waiting to get the ->cleaner_mutex, and a snapshotdeletion was running, and then the box crashed, we would come up in astate where we have a half deleted snapshot.Again, in the normal case the snapshot deletion needs to complete beforerelocation can start, but in this case relocation could very well startbefore the snapshot deletion completes, as we simply add the root to thedead roots list and wait for the next time the cleaner runs to clean upthe snapshot.Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's thathad a pending drop_progress key. If they do then we know we were in themiddle of the drop operation and set a flag on the fs_info. Thenbalance can wait until this flag is cleared to start up again.If there are DEAD_ROOT's that don't have a drop_progress set then we'resafe to start balance right away as we'll be properly protected by thecleaner_mutex.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we're operating on annon-uptodate page. Our overnight tests caught this warning earlier thisweek WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ("btrfs: clear extent bufferuptodate when we fail to write it"), however all that fix did was keepus from finding extent buffers after a failed writeout. It didn't keepus from continuing to use a buffer that we already had found.In this case we're searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing. After the switch we can look up an extentbuffer that hasn't been written yet and start processing that blockgroup. Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we're protected by the tree lock to a certain degree here. Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write. However thisisn't necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon't save us here. We'll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we've "read" a block butit's not marked Uptodate. On read we ClearPageError(), so if we're!Uptodate and !Error we know we didn't do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we're using it, and we'll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we're messing with it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: get rid of warning on transaction commit when using flushoncommitWhen using the flushoncommit mount option, during almost every transactioncommit we trigger a warning from __writeback_inodes_sb_nr(): $ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)The trace produced in dmesg looks like the following: [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]---This is because we started using writeback_inodes_sb() to flush delallocwhen committing a transaction (when using -o flushoncommit), in order toavoid deadlocks with filesystem freeze operations. This change was madeby commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_rootsin flushoncommit"). After that change we started producing that warning,and every now and then a user reports this since the warning happens toooften, it spams dmesg/syslog, and a user is unsure if this reflects anyproblem that might compromise the filesystem's reliability.We can not just lock the sb->s_umount semaphore before callingwriteback_inodes_sb(), because that would at least deadlock withfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()is called while we are holding that semaphore in write mode, and that cantrigger a transaction commit, resulting in a deadlock. It would alsotrigger the same type of deadlock in the unmount path. Possibly, it couldalso introduce some other locking dependencies that lockdep would report.To fix this call try_to_writeback_inodes_sb() instead ofwriteback_inodes_sb(), because that will try to read lock sb->s_umountand then will only call writeback_inodes_sb() if it was able to lock it.This is fine because the cases where it can't read lock sb->s_umountare during a filesystem unmount or during a filesystem freeze - in thosecases sb->s_umount is write locked and sync_filesystem() is called, whichcalls writeback_inodes_sb(). In other words, in all cases where we can'ttake a read lock on sb->s_umount, writeback is already being triggeredelsewhere.An alternative would be to call btrfs_start_delalloc_roots() with anumber of pages different from LONG_MAX, for example matching the numberof delalloc bytes we currently have, in ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: fix oops caused by irqsoff latency tracerThe trace_hardirqs_{on,off}() require the caller to setup frame pointerproperly. This because these two functions use macro 'CALLER_ADDR1' (aka.__builtin_return_address(1)) to acquire caller info. If the $fp is usedfor other purpose, the code generated this macro (as below) could triggermemory access fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault hereThe oops message during booting if compiled with 'irqoff' tracer enabled:[ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8[ 0.041925][ T0] Oops [#1][ 0.042063][ T0] Modules linked in:[ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29[ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT)[ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2[ 0.044601][ T0] ra : restore_all+0x12/0x6e[ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0[ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020[ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0[ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100[ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000[ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45[ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50[ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8[ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000[ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000[ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368[ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d[ 0.046402][ T0] [] restore_all+0x12/0x6eThis because the $fp(aka. $s0) register is not used as frame pointer in theassembly entry code. resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_allTo fix above issue, here we add one extra level wrapper for functiontrace_hardirqs_{on,off}() so they can be safely called by low level entrycode.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48933 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memory leak during stateful obj updatestateful objects can be updated from the control plane.The transaction logic allocates a temporary object for this purpose.The ->init function was called for this object, so plain kfree() leaksresources. We must call ->destroy function of the object.nft_obj_destroy does this, but it also decrements the module refcount,but the update path doesn't increment it.To avoid special-casing the update object release, do module_get forthe update case too and release it via nft_obj_destroy().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: mt7621: Add sentinel to quirks tableCurrent driver is missing a sentinel in the struct soc_device_attributearray, which causes an oops when assessed by thesoc_device_match(mt7621_pcie_quirks_match) call.This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attrwas fixed to register the SOC as a device, in:commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")Fix it by adding the required sentinel.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix crash when replugging CSR fake controllersIt seems fake CSR 5.0 clones can cause the suspend notifier to beregistered twice causing the following kernel panic:[ 71.986122] Call Trace:[ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60[ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da][ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477][ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300[ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90[ 71.986167] usb_probe_interface+0xe3/0x2b0[ 71.986171] really_probe+0xdb/0x380[ 71.986174] ? pm_runtime_barrier+0x54/0x90[ 71.986177] __driver_probe_device+0x78/0x170[ 71.986180] driver_probe_device+0x1f/0x90[ 71.986183] __device_attach_driver+0x89/0x110[ 71.986186] ? driver_allows_async_probing+0x70/0x70[ 71.986189] bus_for_each_drv+0x8c/0xe0[ 71.986192] __device_attach+0xb2/0x1e0[ 71.986195] bus_probe_device+0x92/0xb0[ 71.986198] device_add+0x422/0x9a0[ 71.986201] ? sysfs_merge_group+0xd4/0x110[ 71.986205] usb_set_configuration+0x57a/0x820[ 71.986208] usb_generic_driver_probe+0x4f/0x70[ 71.986211] usb_probe_device+0x3a/0x110[ 71.986213] really_probe+0xdb/0x380[ 71.986216] ? pm_runtime_barrier+0x54/0x90[ 71.986219] __driver_probe_device+0x78/0x170[ 71.986221] driver_probe_device+0x1f/0x90[ 71.986224] __device_attach_driver+0x89/0x110[ 71.986227] ? driver_allows_async_probing+0x70/0x70[ 71.986230] bus_for_each_drv+0x8c/0xe0[ 71.986232] __device_attach+0xb2/0x1e0[ 71.986235] bus_probe_device+0x92/0xb0[ 71.986237] device_add+0x422/0x9a0[ 71.986239] ? _dev_info+0x7d/0x98[ 71.986242] ? blake2s_update+0x4c/0xc0[ 71.986246] usb_new_device.cold+0x148/0x36d[ 71.986250] hub_event+0xa8a/0x1910[ 71.986255] process_one_work+0x1c4/0x380[ 71.986259] worker_thread+0x51/0x390[ 71.986262] ? rescuer_thread+0x3b0/0x3b0[ 71.986264] kthread+0xdb/0x110[ 71.986266] ? kthread_complete_and_exit+0x20/0x20[ 71.986268] ret_from_fork+0x1f/0x30[ 71.986273] [ 71.986274] ---[ end trace 0000000000000000 ]---[ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix memory leak in sctp_stream_outq_migrate()When sctp_stream_outq_migrate() is called to release stream out resources,the memory pointed to by prio_head in stream out is not released.The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: re-fetch skb cb after tipc_msg_validateAs the call trace shows, the original skb was freed in tipc_msg_validate(),and dereferencing the old skb cb would cause an use-after-free crash. BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Call Trace: tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Freed by task 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc]This patch fixes it by re-fetching the skb cb from the new allocated skbafter calling tipc_msg_validate().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49030 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Handle size overflow for ringbuf mmapThe maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entrieswill overflow u32 when mapping producer page and data pages. Onlycasting max_entries to size_t is not enough, because for 32-bitsapplication on 64-bits kernel the size of read-only mmap regionalso could overflow size_t.So fixing it by casting the size of read-only mmap region into a __u64and checking whether or not there will be overflow during mmap.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix panic when growing a memfd_secretWhen one tries to grow an existing memfd_secret with ftruncate, one getsa panic [1]. For example, doing the following reliably induces thepanic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20);The basic reason for this is, when we grow with ftruncate, we call downinto simple_setattr, and then truncate_inode_pages_range, and eventuallywe try to zero part of the memory. The normal truncation code does thisvia the direct map (i.e., it calls page_address() and hands that tomemset()).For memfd_secret though, we specifically don't map our pages via thedirect map (i.e. we call set_direct_map_invalid_noflush() on everyfault). So the address returned by page_address() isn't useful, andwhen we try to memset() with it we panic.This patch avoids the panic by implementing a custom setattr formemfd_secret, which detects resizes specifically (setting the size forthe first time works just fine, since there are no existing pages to tryto zero), and rejects them with EINVAL.One could argue growing should be supported, but I think that willrequire a significantly more lengthy change. So, I propose a minimalfix for the benefit of stable kernels, and then perhaps to extendmemfd_secret to support growing in a separate patch.[1]: BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028[lkp@intel.com: secretmem_iops can be static][axelrasmussen@google.com: return EINVAL]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve overflow the qgroup limitWe use extent_changeset->bytes_changed in qgroup_reserve_data() to recordhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently thebytes_changed is set as "unsigned int", and it will overflow if we try tofallocate a range larger than 4GiB. The result is we reserve less bytesand eventually break the qgroup limit.Unlike regular buffered/direct write, which we use one changeset foreach ordered extent, which can never be larger than 256M. Forfallocate, we use one changeset for the whole range, thus it no longerrespects the 256M per extent limit, and caused the problem.The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNTWhen running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiBSince we have no control of how bytes_changed is used, it's better toset it to u64.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix a race in rxrpc_exit_net()Current code can lead to the following race:CPU0 CPU1rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work);rxrpc_exit_net() exits while peer_keepalive_timer is still armed,leading to use-after-free.syzbot report was:ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505Modules linked in:CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix slab-out-of-bounds bug in decrypt_internalThe memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting intls_set_sw_offload(). The return value of crypto_aead_ivsize()for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytesmemory space will trigger slab-out-of-bounds bug as following:==================================================================BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]Read of size 16 at addr ffff888114e84e60 by task tls/10911Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls]Allocated by task 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_sizewhen memcpy() iv value in TLS_1_3_VERSION scenario.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: Fix frames flush failure caused by deadlockWe are seeing below warnings:kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_workhas no chance to run in 5 seconds.By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasingATH11K_FLUSH_TIMEOUT to 50 we get below warnings:kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.kernel: [ 120.763169] Not tainted 5.10.90 #12kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0kernel: [ 120.763201] Call Trace:kernel: [ 120.763214] __schedule+0x785/0x12fakernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bbkernel: [ 120.763242] schedule+0x7e/0xa1kernel: [ 120.763253] schedule_timeout+0x98/0xfekernel: [ 120.763266] ? run_local_timers+0x4a/0x4akernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2ekernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763802] ? genl_rcv+0x36/0x36kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7kernel: [ 120.763829] genl_rcv+0x28/0x36kernel: [ 120.763840] netlink_unicast+0x179/0x24bkernel: [ 120.763854] netlink_sendmsg+0x393/0x401kernel: [ 120.763872] sock_sendmsg+0x72/0x76kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1kernel: [ 120.763940] __sys_sendmsg+0x85/0xbfkernel: [ 120.763956] do_syscall_64+0x43/0x55kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002ekernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980kernel: [ 120.764032] R13: 00007ffe604---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: svm range restore work deadlock when process exitkfd_process_notifier_release flush svm_range_restore_workwhich calls svm_range_list_lock_and_flush_work to flush deferred_listwork, but if deferred_list work mmput release the last user, it willcall exit_mmap -> notifier_release, it is deadlock with below backtrace.Move flush svm_range_restore_work to kfd_process_wq_release to avoiddeadlock. Then svm_range_restore_work take task->mm ref to avoid mm isgone while validating and mapping ranges to GPU.Workqueue: events svm_range_deferred_list_work [amdgpu]Call Trace: wait_for_completion+0x94/0x100 __flush_work+0x12a/0x1e0 __cancel_work_timer+0x10e/0x190 cancel_delayed_work_sync+0x13/0x20 kfd_process_notifier_release+0x98/0x2a0 [amdgpu] __mmu_notifier_release+0x74/0x1f0 exit_mmap+0x170/0x200 mmput+0x5d/0x130 svm_range_deferred_list_work+0x104/0x230 [amdgpu] process_one_work+0x220/0x3c0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum: Guard against invalid local portsWhen processing events generated by the device's firmware, the driverprotects itself from events reported for non-existent local ports, butnot for the CPU port (local port 0), which exists, but does not have allthe fields as any local port.This can result in a NULL pointer dereference when trying access'struct mlxsw_sp_port' fields which are not initialized for CPU port.Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")already handled such issue by bailing early when processing a PUDE eventreported for the CPU port.Generalize the approach by moving the check to a common function andmaking use of it in all relevant places.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49142 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: preserve skb_end_offset() in skb_unclone_keeptruesize()syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len)in skb_try_coalesce() [1]I was able to root cause the issue to kfence.When kfence is in action, the following assertion is no longer true:int size = xxxx;void *ptr1 = kmalloc(size, gfp);void *ptr2 = kmalloc(size, gfp);if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2));We attempted to fix these issues in the blamed commits, but forgotthat TCP was possibly shifting data after skb_unclone_keeptruesize()has been used, notably from tcp_retrans_try_collapse().So we not only need to keep same skb->truesize value,we also need to make sure TCP wont fill new tailroomthat pskb_expand_head() was able to get from aaddr = kmalloc(...) followed by ksize(addr)Split skb_unclone_keeptruesize() into two parts:1) Inline skb_unclone_keeptruesize() for the common case, when skb is not cloned.2) Out of line __skb_unclone_keeptruesize() for the 'slow path'.WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295Modules linked in:CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 faRSP: 0018:ffffc900063af268 EFLAGS: 00010293RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix memory leak of uid in files registrationWhen there are no files for __io_sqe_files_scm() to process in therange, it'll free everything and return. However, it forgets to put uid.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix call timer start racing with call destructionThe rxrpc_call struct has a timer used to handle various timed eventsrelating to a call. This timer can get started from the packet inputroutines that are run in softirq mode with just the RCU read lock held.Unfortunately, because only the RCU read lock is held - and neither ref orother lock is taken - the call can start getting destroyed at the same timea packet comes in addressed to that call. This causes the timer - whichwas already stopped - to get restarted. Later, the timer dispatch code maythen oops if the timer got deallocated first.Fix this by trying to take a ref on the rxrpc_call struct and, ifsuccessful, passing that ref along to the timer. If the timer was alreadyrunning, the ref is discarded.The timer completion routine can then pass the ref along to the call's workitem when it queues it. If the timer or work item where alreadyqueued/running, the extra ref is discarded.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probeThe device_node pointer is returned by of_parse_phandle() with refcountincremented. We should use of_node_put() on it when done.This function only calls of_node_put() in the regular path.And it will cause refcount leak in error paths.Fix this by calling of_node_put() in error handling too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not double complete bio on errors during compressed readsI hit some weird panics while fixing up the error handling frombtrfs_lookup_bio_sums(). Turns out the compression path will completethe bio we use if we set up any of the compression bios and then returnan error, and then btrfs_submit_data_bio() will also call bio_endio() onthe bio.Fix this by making btrfs_submit_compressed_read() responsible forcalling bio_endio() on the bio if there are any errors. Currently itwas only doing it if we created the compression bios, otherwise it wasdepending on btrfs_submit_data_bio() to do the right thing. Thiscreates the above problem, so fix up btrfs_submit_compressed_read() toalways call bio_endio() in case of an error, and then simply return frombtrfs_submit_data_bio() if we had to callbtrfs_submit_compressed_read().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49168 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not clean up repair bio if submit failsThe submit helper will always run bio_endio() on the bio if it fails tosubmit, so cleaning up the bio just leads to a variety of use-after-freeand NULL pointer dereference bugs because we race with the endiofunction that is cleaning up the bio. Instead just return BLK_STS_OK asthe repair function has to continue to process the rest of the pages,and the endio for the repair bio will do the appropriate cleanup for thepage that it was given.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49178 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memstick/mspro_block: fix handling of read-only devicesUse set_disk_ro to propagate the read-only state to the block layerinstead of checking for it in ->open and leaking a reference in caseof a read-only device.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmemmemory"), we could get a resource allocated during boot viaalloc_resource(). And it's required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mxser: fix xmit_buf leak in activate when LSR == 0xffWhen LSR is 0xff in ->activate() (rather unlike), we return an error.Provided ->shutdown() is not called when ->activate() fails, nothingactually frees the buffer in this case.Fix this by properly freeing the buffer in a designated label. We jumpthere also from the "!info->type" if now too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix more uncharged while msg has more_dataIn tcp_bpf_send_verdict(), if msg has more data aftertcp_bpf_sendmsg_redir():tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_allocThe msg->sg.size(11000) has been uncharged twice, to fix we can charge theremaining msg->sg.size before goto more data.This issue can cause the following info:WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix double uncharge the mem of sk_msgIf tcp_bpf_sendmsg is running during a tear down operation, psock may befreed.tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free()The mem of msg has been uncharged in tcp_bpf_send_verdict() bysk_msg_return(), and would be uncharged by sk_msg_free() again. When psockis null, we can simply returning an error code, this would then triggerthe sk_msg_free_nocharge in the error path of __SK_REDIRECT and would havethe side effect of throwing an error up to user space. This would be aslight change in behavior from user side but would look the same as anerror if the redirect on the socket threw an error.This issue can cause the following info:WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in sk_psock_queue_msgIf tcp_bpf_sendmsg is running during a tear down operation we may enqueuedata on the ingress msg queue while tear down is trying to free it. sk1 (redirect sk2) sk2 ------------------- ---------------tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock()While drop_sk_msg(), the msg has charged memory form sk by sk_mem_chargeand has sg pages need to put. To fix we use sk_msg_free() and then kfee()msg.This issue can cause the following info:WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49209 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is fullIf tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partialmemory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size isgreater than osize after sk_msg_alloc(), memleak occurs. To fix we usesk_msg_trim() to release the allocated memory, then goto wait for memory.Other call paths of sk_msg_alloc() have the similar issue, such astls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),as Cong Wang suggested.This issue can cause the following info:WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race at socket teardownFix a race in the xsk socket teardown code that can lead to a NULL pointerdereference splat. The current xsk unbind code in xsk_unbind_dev() starts bysetting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for anyNAPI processing to terminate using synchronize_net(). After that, the releasecode starts to tear down the socket state and free allocated memory. BUG: kernel NULL pointer dereference, address: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2 Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Call Trace: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xaeThere are two problems with the current code. First, setting xs->dev to NULLbefore waiting for all users to stop using the socket is not correct. Theentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()are all guarded by a test that xs->state is in the state XSK_BOUND and if not,it returns right away. But one process might have passed this test but stillhave not gotten to the point in which it uses xs->dev in the code. In thisinterim, a second process executing xsk_unbind_dev() might have set xs->dev toNULL which will lead to a crash for the first process. The solution here isjust to get rid of this NULL assignment since it is not used anymore. Beforecommit 42fddcc7c64b ("xsk: use state member for socket synchronization"),xs->dev was the gatekeeper to admit processes into the data plane functions,but it was replaced with the state variable xs->state in the aforementionedcommit.The second problem is that synchronize_net() does not wait for any process inxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that thestate they rely on might be cleaned up prematurely. This can happen when thenotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().Solve this by extending the RCU critical region from just the ndo_xsk_wakeupto the whole functions mentioned above, so that both the test of xs->state ==XSK_BOUND and the last use of any member of xs is covered by the RCU criticalsection. This will guarantee that when synchronize_net() completes, there willbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() andstate can be cleaned up safely. Note that we need to drop the RCU lock for theskb xmit path as it uses functions that might sleep. Due to this, we have toretest the xs->state after we grab the mutex that protects the skb xmit codefrom, among a number of things, an xsk_unbind_dev() being executed from thenotifier at the same time.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: fix memory leak during D3hot to D0 transitionIf 'vfio_pci_core_device::needs_pm_restore' is set (PCI device doesnot have No_Soft_Reset bit set in its PMCSR config register), thenthe current PCI state will be saved locally in'vfio_pci_core_device::pm_save' during D0->D3hot transition and samewill be restored back during D3hot->D0 transition.For saving the PCI state locally, pci_store_saved_state() is beingused and the pci_load_and_free_saved_state() will free the allocatedmemory.But for reset related IOCTLs, vfio driver calls PCI reset-relatedAPI's which will internally change the PCI power state back to D0. So,when the guest resumes, then it will get the current state as D0 and itwill skip the call to vfio_pci_set_power_state() for changing thepower state to D0 explicitly. In this case, the memory pointed by'pm_save' will never be freed. In a malicious sequence, the state changingto D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can berun in a loop and it can cause an OOM situation.This patch frees the earlier allocated memory first before overwriting'pm_save' to prevent the mentioned memory leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dax: make sure inodes are flushed before destroy cacheA bug can be triggered by following command$ modprobe nd_pmem && modprobe -r nd_pmem[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)[ 10.062433] Call Trace:[ 10.062673] dump_stack_lvl+0x34/0x44[ 10.062865] slab_err+0x90/0xd0[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0[ 10.063848] kmem_cache_destroy+0x4a/0x110[ 10.064058] __x64_sys_delete_module+0x265/0x300This is caused by dax_fs_exit() not flushing inodes before destroy cache.To fix this issue, call rcu_barrier() before destroy cache.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Hold port reference until decoder releaseKASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free incxl_decoder_release() where it goes to reference its parent, a cxl_port,to free its id back to port->decoder_ida. BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core] Read of size 8 at addr ffff888119270908 by task kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events kobject_delayed_cleanup Call Trace: dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0The device core only guarantees parent lifetime until all children areunregistered. If a child needs a parent to complete its ->release()callback that child needs to hold a reference to extend the lifetime ofthe parent.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49229 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: unregister virtual clocks when unregistering physical clock.When unregistering a physical clock which has some virtual clocks,unregister the virtual clocks with it.This fixes the following oops, which can be triggered by unloadinga driver providing a PTP clock when it has enabled virtual clocks:BUG: unable to handle page fault for address: ffffffffc04fc4d8Oops: 0000 [#1] PREEMPT SMP NOPTIRIP: 0010:ptp_vclock_read+0x31/0xb0Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49234 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Avoid cross-chip syncing of VLAN filteringChanges to VLAN filtering are not applicable to cross-chipnotifications.On a system like this:.-----. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-' '-1-2-' '-1-2-'Before this change, upon sw1p1 leaving a bridge, a call todsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.In this scenario:.---------. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-3-4-' '-1-2-' '-1-2-'When sw1p4 would leave a bridge, dsa_port_vlan_filtering would becalled for sw2 and sw3 with a non-existing port - leading to arrayout-of-bounds accesses and crashes on mv88e6xxx.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49282 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: quota: fix loop condition at f2fs_quota_sync()cnt should be passed to sb_has_quota_active() instead of type to checkactive quota properly.Moreover, when the type is -1, the compiler with enough inline knowledgecan discard sb_has_quota_active() check altogether, causing a NULL pointerdereference at the following inode_lock(dqopt->files[cnt]):[ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 2.796024] Mem abort info:[ 2.796025] ESR = 0x96000005[ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits[ 2.796029] SET = 0, FnV = 0[ 2.796031] EA = 0, S1PTW = 0[ 2.796032] Data abort info:[ 2.796034] ISV = 0, ISS = 0x00000005[ 2.796035] CM = 0, WnR = 0[ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000[ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000[ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1[ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)[ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO)[ 2.796065] pc : down_write+0x28/0x70[ 2.796070] lr : f2fs_quota_sync+0x100/0x294[ 2.796071] sp : ffffffa3f48ffc30[ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000[ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80[ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001[ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000[ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110[ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038[ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0[ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0[ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000[ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948[ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0[ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a[ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d[ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001[ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0[ 2.796098] Call trace:[ 2.796100] down_write+0x28/0x70[ 2.796102] f2fs_quota_sync+0x100/0x294[ 2.796104] block_operations+0x120/0x204[ 2.796106] f2fs_write_checkpoint+0x11c/0x520[ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34[ 2.796109] issue_checkpoint_thread+0x6c/0xb8[ 2.796112] kthread+0x138/0x414[ 2.796114] ret_from_fork+0x10/0x18[ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02)[ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]---[ 2.800116] Kernel panic - not syncing: Fatal exception[ 2.800120] SMP: stopping secondary CPUs

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49325 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add accessors to read/set tp->snd_cwndWe had various bugs over the years with codebreaking the assumption that tp->snd_cwnd is greaterthan zero.Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) addedin commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")can trigger, and without a repro we would have to spendconsiderable time finding the bug.Instead of complaining too late, we want to catch whereand when tp->snd_cwnd is set to an illegal value.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix tcp_mtup_probe_success vs wrong snd_cwndsyzbot got a new report [1] finally pointing to a very old bug,added in initial support for MTU probing.tcp_mtu_probe() has checks about starting an MTU probe iftcp_snd_cwnd(tp) >= 11.But nothing prevents tcp_snd_cwnd(tp) to be reduced laterand before the MTU probe succeeds.This bug would lead to potential zero-divides.Debugging added in commit 40570375356c ("tcp: add accessorsto read/set tp->snd_cwnd") has paid off :)While we are at it, address potential overflows in this code.[1]WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Modules linked in:CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ffRSP: 0018:ffffc900079e70f8 EFLAGS: 00010287RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9fRBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f6431289109Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000aRBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49333 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: E-Switch, pair only capable devicesOFFLOADS paring using devcom is possible only on devicesthat support LAG. Filter based on lag capabilities.This fixes an issue where mlx5_get_next_phys_dev() wascalled without holding the interface lock.This issue was found when commitbc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")added an assert that verifies the interface lock is held.WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ffRSP: 0018:ffff88811bf47458 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49340 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip_gre: test csum_start instead of transport headerGRE with TUNNEL_CSUM will apply local checksum offload onCHECKSUM_PARTIAL packets.ipgre_xmit must validate csum_start after an optional skb_pull,else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL;This had false positives when skb_checksum_start is undefined:when ip_summed is not CHECKSUM_PARTIAL. A discussed refinementwas straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL;But was eventually revised more thoroughly:- restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull.- test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath.Turns out skbs can arrive in this branch without the transportheader set, e.g., through BPF redirection.Revise the check back to check csum_start directly, and only ifCHECKSUM_PARTIAL. Do leave the check in the updated location.Check field regardless of whether TUNNEL_CSUM is configured.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49344 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix a data-race in unix_dgram_peer_wake_me().unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'slock held and check if its receive queue is full. Here we need touse unix_recvq_full_lockless() instead of unix_recvq_full(), otherwiseKCSAN will report a data-race.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49358 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: memleak flow rule from commit pathAbort path release flow rule object, however, commit path does not.Update code to destroy these objects before releasing the transaction.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49359 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panfrost: Job should reference MMU not file_privFor a while now it's been allowed for a MMU context to outlive it'scorresponding panfrost_priv, however the job structure still referencespanfrost_priv to get hold of the MMU context. If panfrost_priv has beenfreed this is a use-after-free which I've been able to trigger resultingin a splat.To fix this, drop the reference to panfrost_priv in the job structureand add a direct reference to the MMU structure which is what's actuallyneeded.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_rtx_synack() can be called from process contextLaurent reported the enclosed report [1]This bug triggers with following coditions:0) Kernel built with CONFIG_DEBUG_PREEMPT=y1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one.2) A socket operation on this socket goes through lock_sock() release_sock() dance.3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog.4) At release_sock() time, the socket backlog is processed while in process context.5) A SYNACK packet is cooked in response of the SYN retransmit.6) -> tcp_rtx_synack() is called in process context.Before blamed commit, tcp_rtx_synack() was always called from BH handler,from a timer handler.Fix this by using TCP_INC_STATS() & NET_INC_STATS()which do not assume caller is in non preemptible context.[1]BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180caller is tcp_rtx_synack.part.0+0x36/0xc0CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49374 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: check attribute length for bearer namesyzbot reported uninit-value:=====================================================BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.- Do not use 'illegal name' in printing message.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49388 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: ubi_create_volume: Fix use-after-free when volume creation failedThere is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'serror handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tblout_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAFFix it by removing redundant 'eba_tbl' releasing.Fetch a reproducer in [Link].

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49390 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:macsec: fix UAF bug for real_devCreate a new macsec device but not get reference to real_dev. That cannot ensure that real_dev is freed after macsec. That will trigger theUAF bug for real_dev as following:==================================================================BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), wecan add dev_hold_track() in macsec_dev_init() and dev_put_track() inmacsec_free_netdev() to fix the problem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49395 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: Fix out-of-bounds read in LDT setupsyscall_stub_data() expects the data_count parameter to be the number oflongs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate races around sk->sk_bound_dev_ifUDP sendmsg() is lockless, and reads sk->sk_bound_dev_if whilethis field can be changed by another thread.Adds minimal annotations to avoid KCSAN splats for UDP.Following patches will add more annotations to potential lockless readers.BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsgwrite to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0x00000000 -> 0xffffff9bReported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011I chose to not add Fixes: tag because race has minor consequencesand stable teams busy enough.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49439 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fsl_rio: Fix refcount leak in fsl_rio_setupof_parse_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49446 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm: Fix firmware activation deadlock scenariosLockdep reports the following deadlock scenarios for CXL root devicepower-management, device_prepare(), operations, and device_shutdown()operations for 'nd_region' devices: Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key);These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()which walks the entire system device topology taking device_lock() alongthe way. The nvdimm_bus_lock() is protecting against unregistration,multiple simultaneous ops callers, and preventing activate_show() fromracing activate_store(). For the first 2, the lock is redundant.Unregistration already flushes all ops users, and sysfs already preventsmultiple threads to be active in an ops handler at the same time. Forthe last userspace should already be waiting for its lastactivate_store() to complete, and does not need activate_show() to flushthe write side, so this lock usage can be deleted in these attributes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix listen() setting the bar too high for the prealloc ringsAF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bumpup the sysctl), but whilst the preallocation circular buffers have 32 slotsin them, one of them has to be a dead slot because we're using CIRC_CNT().This means that listen(rxrpc_sock, 32) will cause an oops when the socketis closed because rxrpc_service_prealloc_one() allocated one too many callsand rxrpc_discard_prealloc() won't then be able to get rid of them becauseit'll think the ring is empty. rxrpc_release_calls_on_socket() then triesto abort them, but oopses because call->peer isn't yet set.Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to matchthe ring capacity. BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49469 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix anon_dev leak in create_subvol()When btrfs_qgroup_inherit(), btrfs_alloc_tree_block, orbtrfs_insert_root() fail in create_subvol(), we return without freeinganon_dev. Reorganize the error handling in create_subvol() to fix this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49470 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_eventWe should not access skb buffer data anymore after hci_recv_frame wascalled.[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker[ 39.634962] Call trace:[ 39.634974] dump_backtrace+0x0/0x3b8[ 39.634999] show_stack+0x20/0x2c[ 39.635016] dump_stack_lvl+0x60/0x78[ 39.635040] print_address_description+0x70/0x2f0[ 39.635062] kasan_report+0x154/0x194[ 39.635079] __asan_report_load1_noabort+0x44/0x50[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4[ 39.635157] process_one_work+0x560/0xc5c[ 39.635177] worker_thread+0x7ec/0xcc0[ 39.635195] kthread+0x2d0/0x3d0[ 39.635215] ret_from_fork+0x10/0x20[ 39.635247] Allocated by task 0:[ 39.635260] (stack is not available)[ 39.635281] Freed by task 2392:[ 39.635295] kasan_save_stack+0x38/0x68[ 39.635319] kasan_set_track+0x28/0x3c[ 39.635338] kasan_set_free_info+0x28/0x4c[ 39.635357] ____kasan_slab_free+0x104/0x150[ 39.635374] __kasan_slab_free+0x18/0x28[ 39.635391] slab_free_freelist_hook+0x114/0x248[ 39.635410] kfree+0xf8/0x2b4[ 39.635427] skb_free_head+0x58/0x98[ 39.635447] skb_release_data+0x2f4/0x410[ 39.635464] skb_release_all+0x50/0x60[ 39.635481] kfree_skb+0xc8/0x25c[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth][ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth][ 39.635925] process_one_work+0x560/0xc5c[ 39.635951] worker_thread+0x7ec/0xcc0[ 39.635970] kthread+0x2d0/0x3d0[ 39.635990] ret_from_fork+0x10/0x20[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512[ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49471 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: cfo: check mac_id to avoid out-of-boundsSomehow, hardware reports incorrect mac_id and pollute memory. Check indexbefore we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: fix kernel crash at mt7921_pci_removeThe crash log shown it is possible that mt7921_irq_handler is called whiledevm_free_irq is being handled so mt76_free_device need to be postponeduntil devm_free_irq is completed to solve the crash we free the mt76 devicetoo early.[ 9299.339655] BUG: kernel NULL pointer dereference, address: 0000000000000008[ 9299.339705] #PF: supervisor read access in kernel mode[ 9299.339735] #PF: error_code(0x0000) - not-present page[ 9299.339768] PGD 0 P4D 0[ 9299.339786] Oops: 0000 [#1] SMP PTI[ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1[ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022[ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e][ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082[ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5[ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020[ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011[ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080[ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228[ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000[ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0[ 9299.340432] PKRU: 55555554[ 9299.340449] Call Trace:[ 9299.340467] [ 9299.340485] __free_irq+0x221/0x350[ 9299.340527] free_irq+0x30/0x70[ 9299.340553] devm_free_irq+0x55/0x80[ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e][ 9299.340616] pci_device_remove+0x3b/0xa0[ 9299.340651] __device_release_driver+0x17a/0x240[ 9299.340686] device_driver_detach+0x3c/0xa0[ 9299.340714] unbind_store+0x113/0x130[ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0[ 9299.340775] new_sync_write+0x15c/0x1f0[ 9299.340806] vfs_write+0x1d2/0x270[ 9299.340831] ksys_write+0x67/0xe0[ 9299.340857] do_syscall_64+0x3b/0x90[ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49484 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vectorFix possible NULL pointer dereference in mt7915_mac_fill_rx_vectorroutine if the chip does not support dbdc and the hw reports band_idxset to 1.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49496 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.koIf the driver support subdev mode, the parameter "dev->pm.dev" will beNULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmodmtk-vcodec-dec.ko.[ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80[ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c[ 4380.711509] sp : ffff80000819bc10[ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000[ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220[ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020[ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976[ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040[ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000[ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc[ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000[ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208[ 4380.786031] Call trace:[ 4380.788465] do_raw_spin_trylock+0x4/0x80[ 4380.792462] __pm_runtime_disable+0x2c/0x1b0[ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec][ 4380.802466] platform_remove+0x2c/0x60[ 4380.806204] __device_release_driver+0x194/0x250[ 4380.810810] driver_detach+0xc8/0x15c[ 4380.814462] bus_remove_driver+0x5c/0xb0[ 4380.818375] driver_unregister+0x34/0x64[ 4380.822288] platform_driver_unregister+0x18/0x24[ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec][ 4380.833240] __arm64_sys_delete_module+0x190/0x224[ 4380.838020] invoke_syscall+0x48/0x114[ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c[ 4380.846540] do_el0_svc+0x28/0x90[ 4380.849844] el0_svc+0x4c/0x100[ 4380.852975] el0t_64_sync_handler+0xec/0xf0[ 4380.857148] el0t_64_sync+0x190/0x194[ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49497 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: remove two BUG() from skb_checksum_help()I have a syzbot report that managed to get a crash in skb_checksum_help()If syzbot can trigger these BUG(), it makes sense to replacethem with more friendly WARN_ON_ONCE() since skb_checksum_help()can instead return an error code.Note that syzbot will still crash there, until real bug is fixed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49513 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: Use kobject release() method to free dbs_dataThe struct dbs_data embeds a struct gov_attr_set andthe struct gov_attr_set embeds a kobject. Since every kobject must havea release() method and we can't use kfree() to free it directly,so introduce cpufreq_dbs_data_release() to release the dbs_data viathe kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4[ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49516 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: always check VF VSI pointer valuesThe ice_get_vf_vsi function can return NULL in some cases, such as ifhandling messages during a reset where the VSI is being removed andrecreated.Several places throughout the driver do not bother to check whether thisVSI pointer is valid. Static analysis tools maybe report issues becausethey detect paths where a potentially NULL pointer could be dereferenced.Fix this by checking the return value of ice_get_vf_vsi everywhere.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49528 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: dw9714: Disable the regulator when the driver fails to probeWhen the driver fails to probe, we will get the following splat:[ 59.305988] ------------[ cut here ]------------[ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0[ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0[ 59.318362] Call Trace:[ 59.318582] [ 59.318765] regulator_put+0x1f/0x30[ 59.319058] devres_release_group+0x319/0x3d0[ 59.319420] i2c_device_probe+0x766/0x940Fix this by disabling the regulator in error handling.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49530 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix double free in si_parse_power_table()In function si_parse_power_table(), array adev->pm.dpm.ps and its memberis allocated. If the allocation of each member fails, the array itselfis freed and returned with an error code. However, the array is laterfreed again in si_dpm_fini() function which is called when the functionreturns an error.This leads to potential double free of the array adev->pm.dpm.ps, aswell as leak of its array members, since the members are not freed inthe allocation function and the array is not nulled when freed.In addition adev->pm.dpm.num_ps, which keeps track of the allocatedarray member, is not updated until the member allocation issuccessfully finished, this could also lead to either use after free,or uninitialized variable access in si_dpm_fini().Fix this by postponing the free of the array until si_dpm_fini() andincrement adev->pm.dpm.num_ps everytime the array member is allocated.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49533 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: Change max no of active probe SSID and BSSID to fw capabilityThe maximum number of SSIDs in a for active probe requests is currentlyreported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver.The scan_req_params structure only has the capacity to hold 10 SSIDs.This leads to a buffer overflow which can be triggered fromwpa_supplicant in userspace. When copying the SSIDs into thescan_req_params structure in the ath11k_mac_op_hw_scan route, it canoverwrite the extraie pointer.Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo proberequest will be sent, so totally 64 probe requests supported. Soset both max ssid and bssid to 16 and 4 respectively. Remove theredundant macros of ssid and bssid.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49538 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: jack: Access input_dev under mutexIt is possible when using ASoC that input_dev is unregistered whilecalling snd_jack_report, which causes NULL pointer dereference.In order to prevent this serialize access to input_dev using mutex lock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49543 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: fix the warning of dev_wake in mhi_pm_disable_transition()When test device recovery with below command, it has warning in messageas below.echo assert > /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crashecho assert > /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crashwarning message:[ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash[ 1968.471364] ieee80211 phy0: Hardware restart was requested[ 1968.511305] ------------[ cut here ]------------[ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi][ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core[ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579[ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021[ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi][ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi][ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89[ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286[ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922[ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24[ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27[ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac[ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24[ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000[ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0[ 1968.512587] Call Trace:[ 1968.512672] [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40[ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi][ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi][ 1968.513063] process_one_work+0x86a/0x1400[ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230[ 1968.513312] ? move_linked_works+0x125/0x290[ 1968.513416] worker_thread+0x6db/0xf60[ 1968.513536] ? process_one_work+0x1400/0x1400[ 1968.513627] kthread+0x241/0x2d0[ 1968.513733] ? kthread_complete_and_exit+0x20/0x20[ 1968.513821] ret_from_fork+0x22/0x30[ 1968.513924] Reason is mhi_deassert_dev_wake() from mhi_device_put() is calledbut mhi_assert_dev_wake() from __mhi_device_get_sync() is not calledin progress of recovery. Commit 8e0559921f9a ("bus: mhi: core:Skip device wake in error or shutdown state") add check for thepm_state of mhi in __mhi_device_get_sync(), and the pm_state is notthe normal state untill recovery is completed, so it leads thedev_wake is not 0 and above warning print in mhi_pm_disable_transition()while checking mhi_cntrl->dev_wake.Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip callmhi_device_put() if mhi_device_get_sync() does not really do wake,then the warning gone.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix potential array overflow in bpf_trampoline_get_progs()The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does notinclude BPF_TRAMP_MODIFY_RETURN bpf programs, so the number ofthe attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampolinecan exceed BPF_MAX_TRAMP_PROGS.When this happens, the assignment '*progs++ = aux->prog' inbpf_trampoline_get_progs() will cause progs array overflow as theprogs field in the bpf_tramp_progs struct can only hold at mostBPF_MAX_TRAMP_PROGS bpf programs.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49552 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix combination of jit blinding and pointers to bpf subprogs.The combination of jit blinding and pointers to bpf subprogs causes:[ 36.989548] BUG: unable to handle page fault for address: 0000000100000001[ 36.990342] #PF: supervisor instruction fetch in kernel mode[ 36.990968] #PF: error_code(0x0010) - not-present page[ 36.994859] RIP: 0010:0x100000001[ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.[ 37.004091] Call Trace:[ 37.004351] [ 37.004576] ? bpf_loop+0x4d/0x70[ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13bThe jit blinding logic didn't recognize that ld_imm64 with an addressof bpf subprogram is a special instruction and proceeded to randomize it.By itself it wouldn't have been an issue, but jit_subprogs() logicrelies on two step process to JIT all subprogs and then JIT themagain when addresses of all subprogs are known.Blinding process in the first JIT phase caused second JIT to missadjustment of special ld_imm64.Fix this issue by ignoring special ld_imm64 instructions that don't haveuser controlled constants and shouldn't be blinded.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49554 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:zsmalloc: fix races between asynchronous zspage free and page migrationThe asynchronous zspage free worker tries to lock a zspage's entire pagelist without defending against page migration. Since pages which haven'tyet been locked can concurrently migrate off the zspage page list whilelock_zspage() churns away, lock_zspage() can suffer from a few differentlethal races.It can lock a page which no longer belongs to the zspage and unsafelydereference page_private(), it can unsafely dereference a torn pointer tothe next page (since there's a data race), and it can observe a spuriousNULL pointer to the next page and thus not lock all of the zspage's pages(since a single page migration will reconstruct the entire page list, andcreate_page_chain() unconditionally zeroes out each list pointer in theprocess).Fix the races by using migrate_read_lock() in lock_zspage() to synchronizewith page migration.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49558 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: double hook unregistration in netns path__nft_release_hooks() is called from pre_netns exit path whichunregisters the hooks, then the NETDEV_UNREGISTER event is triggeredwhich unregisters the hooks again.[ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270[...][ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27[ 565.253682] Workqueue: netns cleanup_net[ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270[...][ 565.297120] Call Trace:[ 565.300900] [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables][ 565.308518] raw_notifier_call_chain+0x63/0x80[ 565.312386] unregister_netdevice_many+0x54f/0xb50Unregister and destroy netdev hook from netns pre_exit via kfree_rcuso the NETDEV_UNREGISTER path see unregistered hooks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49560 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: check if cluster num is validSyzbot reported slab-out-of-bounds read in exfat_clear_bitmap.This was triggered by reproducer calling truncute with size 0,which causes the following trace:BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65Move the is_valid_cluster() helper from fatent.c to a commonheader to make it reusable in other *.c files. And add is_valid_cluster()to validate if cluster number is within valid range in exfat_clear_bitmap()and exfat_set_bitmap().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: re-fetch conntrack after insertionIn case the conntrack is clashing, insertion can free skb->_nfct andset skb->_nfct to the already-confirmed entry.This wasn't found before because the conntrack entry and the extensionspace used to free'd after an rcu grace period, plus the race needsevents enabled to trigger.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix data-races around sysctl_fib_multipath_hash_fields.While reading sysctl_fib_multipath_hash_fields, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Fix data-races around sysctl_tcp_migrate_req.While reading sysctl_tcp_migrate_req, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_qrv.While reading sysctl_igmp_qrv, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49600 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix a data-race around sysctl_ip_autobind_reuse.While reading sysctl_ip_autobind_reuse, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49608 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: ralink: Check for null return of devm_kcallocBecause of the possible failure of the allocation, data->domains mightbe NULL pointer and will cause the dereference of the NULL pointerlater.Therefore, it might be better to check it and directly return -ENOMEMwithout releasing data manually if fails, because the comment of thedevm_kmalloc() says "Memory allocated with this function isautomatically freed on driver detach.".

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49629 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Fix data-races around nexthop_compat_mode.While reading nexthop_compat_mode, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: Fix data-races around sysctl_icmp_echo_enable_probe.While reading sysctl_icmp_echo_enable_probe, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/selftests: fix subtraction overflow bugOn some machines hole_end can be small enough to cause subtractionoverflow. On the other side (addr + 2 * min_alignment) can overflowin case of mock tests. This patch should handle both cases.(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix a data-race around sysctl_fib_sync_mem.While reading sysctl_fib_sync_mem, it can be changed concurrently.So, we need to add READ_ONCE() to avoid a data-race.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49654 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: qca8k: reset cpu port on MTU changeIt was discovered that the Documentation lacks of a fundamental detailon how to correctly change the MAX_FRAME_SIZE of the switch.In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, theswitch panics and cease to send any packet. This cause the mgmt ethernetsystem to not receive any packet (the slow fallback still works) andmakes the device not reachable. To recover from this a switch reset isrequired.To correctly handle this, turn off the cpu ports before changing theMAX_FRAME_SIZE and turn on again after the value is applied.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_valsKuee reported a corner case where the tnum becomes constant after the callto __reg_bound_offset(), but the register's bounds are not, that is, itsmin bounds are still not equal to the register's max bounds.This in turn allows to leak pointers through turning a pointer register asis into an unknown scalar via adjust_ptr_min_max_vals().Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exitWhat can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, thatis, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off hasnot been done at that point via __update_reg_bounds(), which would have improvedthe umax to be equal to umin.Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()helper and use it consistently everywhere. After the fix, bounds have beencorrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the registeris regarded as a 'proper' constant scalar of 0.After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bitsIn commit 1be37d3b0414 ("can: m_can: fix periph RX path: userx-offload to ensure skbs are sent from softirq context") the RX pathfor peripheral devices was switched to RX-offload.Received CAN frames are pushed to RX-offload together with atimestamp. RX-offload is designed to handle overflows of the timestampcorrectly, if 32 bit timestamps are provided.The timestamps of m_can core are only 16 bits wide. So this patchshifts them to full 32 bit before passing them to RX-offload.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49662 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix lockdep splat in in6_dump_addrs()As reported by syzbot, we should not use rcu_dereference()when rcu_read_lock() is not held.WARNING: suspicious RCU usage5.19.0-rc2-syzkaller #0 Not taintednet/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz-executor326/3617: #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223stack backtrace:CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175 inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300 netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380 netlink_dump_start include/linux/netlink.h:245 [inline] rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546 __sys_sendmsg net/socket.c:2575 [inline] __do_sys_sendmsg net/socket.c:2584 [inline] __se_sys_sendmsg net/socket.c:2582 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: move bc link creation back to tipc_node_createShuang Li reported a NULL pointer dereference crash: [] BUG: kernel NULL pointer dereference, address: 0000000000000068 [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc] [] Call Trace: [] [] tipc_bcast_rcv+0xa2/0x190 [tipc] [] tipc_node_bc_rcv+0x8b/0x200 [tipc] [] tipc_rcv+0x3af/0x5b0 [tipc] [] tipc_udp_recv+0xc7/0x1e0 [tipc]It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When itcreates a node in tipc_node_check_dest(), after inserting the new nodeinto hashtable in tipc_node_create(), it creates the bc link. However,there is a gap between this insert and bc link creation, a bc packetmay come in and get the node from the hashtable then try to dereferenceits bc link, which is NULL.This patch is to fix it by moving the bc link creation before insertinginto the hashtable.Note that for a preliminary node becoming "real", the bc link creationshould also be called before it's rehashed, as we don't create it forpreliminary nodes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: do not assume transport header is always setRewrite tests in ip6erspan_tunnel_xmit() anderspan_fb_xmit() to not assume transport header is set.syzbot reported:WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963Modules linked in:CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00RSP: 0018:ffffc90005daf910 EFLAGS: 00010293RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0Call Trace:__netdev_start_xmit include/linux/netdevice.h:4805 [inline]netdev_start_xmit include/linux/netdevice.h:4819 [inline]xmit_one net/core/dev.c:3588 [inline]dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342__dev_xmit_skb net/core/dev.c:3815 [inline]__dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219dev_queue_xmit include/linux/netdevice.h:2994 [inline]tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229kthread+0x2e9/0x3a0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix use-after-free Read in tipc_named_reinitsyzbot found the following issue on:==================================================================BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0net/tipc/name_distr.c:413Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 01/01/2011Workqueue: events tipc_net_finalize_workCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 [...]==================================================================In the commitd966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"),the cancel_work_sync() function just to make sure ONLY the worktipc_net_finalize_work() is executing/pending on any CPU completed beforetipc namespace is destroyed through tipc_exit_net(). But this functionis not guaranteed the work is the last queued. So, the destroyed instancemay be accessed in the work which will try to enqueue later.In order to completely fix, we re-order the calling of cancel_work_sync()to make sure the work tipc_net_finalize_work() was last queued and itmust be completed by calling cancel_work_sync().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49697 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix request_sock leak in sk lookup helpersA customer reported a request_socket leak in a Calico cloud environment. Wefound that a BPF program was doing a socket lookup with takes a refcnt onthe socket and that it was finding the request_socket but returning the parentLISTEN socket via sk_to_full_sk() without decrementing the child request socket1st, resulting in request_sock slab object leak. This patch retains theexisting behaviour of returning full socks to the caller but it also decrementsthe child request_socket if one is present before doing so to prevent the leak.Thanks to Curtis Taylor for all the help in diagnosing and testing this. Andthanks to Antoine Tenart for the reproducer and patch input.v2 of this patch contains, refactor as per Daniel Borkmann's suggestions tovalidate RCU flags on the listen socket so that it balances with bpf_sk_release()and update comments as per Martin KaFai Lau's suggestion. One small change toDaniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extrainstruction.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix hang during unmount when block group reclaim task is runningWhen we start an unmount, at close_ctree(), if we have the reclaim taskrunning and in the middle of a data block group relocation, we can triggera deadlock when stopping an async reclaim task, producing a trace like thefollowing:[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs][629724.501267] Call Trace:[629724.501759] [629724.502174] __schedule+0x3cb/0xed0[629724.502842] schedule+0x4e/0xb0[629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs][629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0[629724.505442] flush_space+0x423/0x630 [btrfs][629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50[629724.507259] ? lock_release+0x220/0x4a0[629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs][629724.508940] ? do_raw_spin_unlock+0x4b/0xa0[629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs][629724.510922] process_one_work+0x252/0x5a0[629724.511694] ? process_one_work+0x5a0/0x5a0[629724.512508] worker_thread+0x52/0x3b0[629724.513220] ? process_one_work+0x5a0/0x5a0[629724.514021] kthread+0xf2/0x120[629724.514627] ? kthread_complete_and_exit+0x20/0x20[629724.515526] ret_from_fork+0x22/0x30[629724.516236] [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000[629724.518269] Call Trace:[629724.518746] [629724.519160] __schedule+0x3cb/0xed0[629724.519835] schedule+0x4e/0xb0[629724.520467] schedule_timeout+0xed/0x130[629724.521221] ? lock_release+0x220/0x4a0[629724.521946] ? lock_acquired+0x19c/0x420[629724.522662] ? trace_hardirqs_on+0x1b/0xe0[629724.523411] __wait_for_common+0xaf/0x1f0[629724.524189] ? usleep_range_state+0xb0/0xb0[629724.524997] __flush_work+0x26d/0x530[629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140[629724.526580] ? lock_acquire+0x1a0/0x310[629724.527324] __cancel_work_timer+0x137/0x1c0[629724.528190] close_ctree+0xfd/0x531 [btrfs][629724.529000] ? evict_inodes+0x166/0x1c0[629724.529510] generic_shutdown_super+0x74/0x120[629724.530103] kill_anon_super+0x14/0x30[629724.530611] btrfs_kill_super+0x12/0x20 [btrfs][629724.531246] deactivate_locked_super+0x31/0xa0[629724.531817] cleanup_mnt+0x147/0x1c0[629724.532319] task_work_run+0x5c/0xa0[629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0[629724.533598] syscall_exit_to_user_mode+0x16/0x40[629724.534200] do_syscall_64+0x48/0x90[629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae[629724.535318] RIP: 0033:0x7fa2b90437a7[629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6[629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7[629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0[629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200[629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000[629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000[629724.541796] This happens because:1) Before entering close_ctree() we have the async block group reclaim task running and relocating a data block group;2) There's an async metadata (or data) space reclaim task running;3) We enter close_ctree() and park the cleaner kthread;4) The async space reclaim task is at flush_space() and runs all the existing delayed iputs;5) Before the async space reclaim task calls btrfs_wait_on_delayed_iputs(), the block group reclaim task which is doing the data block group relocation, creates a delayed iput at replace_file_extents() (called when COWing leaves that have file extent items pointing to relocated data exten---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49706 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:zonefs: fix zonefs_iomap_begin() for readsIf a readahead is issued to a sequential zone file with an offsetexactly equal to the current file size, the iomap type is set toIOMAP_UNWRITTEN, which will prevent an IO, but the iomap length iscalculated as 0. This causes a WARN_ON() in iomap_iter():[17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80[...][17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80[...][17309.754560] Call Trace:[17309.757078] [17309.759240] ? lock_is_held_type+0xd8/0x130[17309.763531] iomap_readahead+0x1a8/0x870[17309.767550] ? iomap_read_folio+0x4c0/0x4c0[17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400[17309.778848] ? lock_release+0x370/0x750[17309.784462] ? folio_add_lru+0x217/0x3f0[17309.790220] ? reacquire_held_locks+0x4e0/0x4e0[17309.796543] read_pages+0x17d/0xb60[17309.801854] ? folio_add_lru+0x238/0x3f0[17309.807573] ? readahead_expand+0x5f0/0x5f0[17309.813554] ? policy_node+0xb5/0x140[17309.819018] page_cache_ra_unbounded+0x27d/0x450[17309.825439] filemap_get_pages+0x500/0x1450[17309.831444] ? filemap_add_folio+0x140/0x140[17309.837519] ? lock_is_held_type+0xd8/0x130[17309.843509] filemap_read+0x28c/0x9f0[17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs][17309.856162] ? trace_contention_end+0xd6/0x130[17309.862416] ? __mutex_lock+0x221/0x1480[17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs][17309.875364] ? filemap_get_pages+0x1450/0x1450[17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620[17309.888248] ? wait_for_completion_io_timeout+0x20/0x20[17309.895231] ? lock_is_held_type+0xd8/0x130[17309.901115] ? lock_is_held_type+0xd8/0x130[17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs][17309.913750] new_sync_read+0x2d8/0x520[17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0Furthermore, this causes iomap_readahead() to loop forever asiomap_readahead_iter() always returns 0, making no progress.Fix this by treating reads after the file size as access to holes,setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDRand using the length argument as is for the iomap length. To simplifythe code with this change, zonefs_iomap_begin() is split into the readvariant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and thewrite variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cfi: Fix __cfi_slowpath_diag RCU usage with cpuidleRCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalidRCU state in the cpuidle code path: WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138 ... Call trace: rcu_eqs_enter+0xe4/0x138 rcu_idle_enter+0xa8/0x100 cpuidle_enter_state+0x154/0x3a8 cpuidle_enter+0x3c/0x58 do_idle.llvm.6590768638138871020+0x1f4/0x2ec cpu_startup_entry+0x28/0x2c secondary_start_kernel+0x1b8/0x220 __secondary_switched+0x94/0x98Instead, call rcu_irq_enter/exit to wake up RCU only when needed anddisable interrupts for the entire CFI shadow/module check when we do.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sock: redo the psock vs ULP protection checkCommit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")has moved the inet_csk_has_ulp(sk) check from sk_psock_init() tothe new tcp_bpf_update_proto() function. I'm guessing that thiswas done to allow creating psocks for non-inet sockets.Unfortunately the destruction path for psock includes the ULPunwind, so we need to fail the sk_psock_init() itself.Otherwise if ULP is already present we'll notice that later,and call tcp_update_ulp() with the sk_proto of the ULPitself, which will most likely result in the ULP loopingits callbacks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49743 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Use "buf" flexible array for memcpy() destinationThe "buf" flexible array needs to be the memcpy() destination to avoidfalse positive run-time warning from the recent FORTIFY_SOURCEhardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: use casting of u64 in clock multiplication to avoid overflowIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflowby depending on the values of the given parameters including the ic_clk.For example in our use case where ic_clk is larger than one million,multiplication of ic_clk * 4700 will result in 32 bit overflow.Add cast of u64 to the calculation to avoid multiplication overflow, anduse the corresponding define for divide.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/highbank: Fix memory leak in highbank_mc_probe()When devres_open_group() fails, it returns -ENOMEM without freeing memoryallocated by edac_mc_alloc().Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49758 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:reset: uniphier-glue: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(res) invoked,if platform_get_resource() returns NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always report error in run_one_delayed_ref()Currently we have a btrfs_debug() for run_one_delayed_ref() failure, butif end users hit such problem, there will be no chance thatbtrfs_debug() is enabled. This can lead to very little useful info fordebugging.This patch will:- Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod- Replace the btrfs_debug() with btrfs_err()- Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller.This error should only be triggered at most once.As if run_one_delayed_ref() failed, we trigger the error message, thencausing the call chain to error out:btrfs_run_delayed_refs()`- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref()And we will abort the current transaction in btrfs_run_delayed_refs().If we have to run delayed refs for the abort transaction,run_one_delayed_ref() will just cleanup the refs and do nothing, thus nonew error messages would be output.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ntfs: check overflow when iterating ATTR_RECORDsKernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the nextATTR_RECORD from end address of current ATTR_RECORD, through currentATTR_RECORD length field.The problem is that during iteration, when kernel calculates the endaddress of current ATTR_RECORD, kernel may trigger an integer overflow bugin executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. Thismay wrap, leading to a forever iteration on 32bit systems.This patch solves it by adding some checks on calculating end addressof current ATTR_RECORD during iteration.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49764 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent bpf program recursion for raw tracepoint probesWe got report from sysbot [1] about warnings that were caused bybpf program attached to contention_begin raw tracepoint triggeringthe same tracepoint by using bpf_trace_printk helper that takestrace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ...The can be reproduced by attaching bpf program as raw tracepoint oncontention_begin tracepoint. The bpf prog calls bpf_trace_printkhelper. Then by running perf bench the spin lock code is forced totake slow path and call contention_begin tracepoint.Fixing this by skipping execution of the bpf program if it'salready running, Using bpf prog 'active' field, which is beingcurrently used by trampoline programs for the same reason.Moving bpf_prog_inc_misses_counter to syscall.c becausetrampoline.c is compiled in just for CONFIG_BPF_JIT option.[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p: trans_fd/p9_conn_cancel: drop client lock earliersyzbot reported a double-lock here and we no longer need thislock after requests have been moved off to local list:just drop the lock earlier.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49785 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Add overflow check in sgx_validate_offset_length()sgx_validate_offset_length() function verifies "offset" and "length"arguments provided by userspace, but was missing an overflow check ontheir addition. Add it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49803 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: Fix memory leak of nsim_dev->fa_cookiekmemleak reports this issue:unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe issue occurs in the following scenarios:nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie..nsim_drv_remove()The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. Tofix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49806 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()sparx_stats_init() calls create_singlethread_workqueue() and notchecked the ret value, which may return NULL. And a null-ptr-deref mayhappen:sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL. So assparx5_start().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: don't leak tagger-owned storage on switch driver unbindIn the initial commit dc452a471dba ("net: dsa: introduce tagger-ownedstorage for private and shared data"), we had a call totag_ops->disconnect(dst) issued from dsa_tree_free(), which is called attree teardown time.There were problems with connecting to a switch tree as a whole, so thisgot reworked to connecting to individual switches within the tree. Inthis process, tag_ops->disconnect(ds) was made to be called only fromswitch.c (cross-chip notifiers emitted as a result of dynamic tag protochanges), but the normal driver teardown code path wasn't replaced withanything.Solve this problem by adding a function that does the opposite ofdsa_switch_setup_tag_protocol(), which is called from the equivalentspot in dsa_switch_teardown(). The positioning here also ensures that wewon't have any use-after-free in tagging protocol (*rcv) ops, since theteardown sequence is as follows:dsa_tree_teardown-> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler-> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many()-> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: don't delete error page from pagecacheThis change is very similar to the change that was made for shmem [1], andit solves the same problem but for HugeTLBFS instead.Currently, when poison is found in a HugeTLB page, the page is removedfrom the page cache. That means that attempting to map or read thathugepage in the future will result in a new hugepage being allocatedinstead of notifying the user that the page was poisoned. As [1] states,this is effectively memory corruption.The fix is to leave the page in the page cache. If the user attempts touse a poisoned HugeTLB page with a syscall, the syscall will fail withEIO, the same error code that shmem uses. For attempts to map the page,the thread will get a BUS_MCEERR_AR SIGBUS.[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: initialize device's zone info for seedingWhen performing seeding on a zoned filesystem it is necessary toinitialize each zoned device's btrfs_zoned_device_info structure,otherwise mounting the filesystem will cause a NULL pointer dereference.This was uncovered by fstests' testcase btrfs/163.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: clone zoned device info when cloning a deviceWhen cloning a btrfs_device, we're not cloning the associatedbtrfs_zoned_device_info structure of the device in case of a zonedfilesystem.Later on this leads to a NULL pointer dereference when accessing thedevice's zone_info for instance when setting a zone as active.This was uncovered by fstests' testcase btrfs/161.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()We got a syzkaller problem because of aarch64 alignment faultif KFENCE enabled. When the size from user bpf program is an oddnumber, like 399, 407, etc, it will cause the struct skb_shared_info'sunaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381To fix the problem, we adjust @size so that (@size + @hearoom) is amultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_infois aligned to a cache line.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfgipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() toobtain the wwan power state configuration from BIOS but isnot freeing the acpi_object. The acpi_evaluate_dsm() returnedacpi_object to be freed.Free the acpi_object after use.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()When prestera_sdma_switch_init() failed, the memory pointed to bysw->rxtx isn't released. Fix it. Only be compiled, not be tested.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapbether: fix issue of invalid opcode in lapbeth_open()If lapb_register() failed when lapb device goes to up for the first time,the NAPI is not disabled. As a result, the invalid opcode issue isreported when the lapb device goes to up for the second time.The stack info is as follows:[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442![ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0[ 1958.332310][T11356] Call Trace:[ 1958.332817][T11356] [ 1958.336135][T11356] lapbeth_open+0x18/0x90[ 1958.337446][T11356] __dev_open+0x258/0x490[ 1958.341672][T11356] __dev_change_flags+0x4d4/0x6a0[ 1958.345325][T11356] dev_change_flags+0x93/0x160[ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0[ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0[ 1958.349638][T11356] sock_ioctl+0x5d1/0x750[ 1958.356059][T11356] __x64_sys_ioctl+0x3ec/0x1790[ 1958.365594][T11356] do_syscall_64+0x35/0x80[ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 1958.377381][T11356]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_headerThis is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-valuein tipc_nl_compat_name_table_dump") where it should have type castedsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negativevalue.syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix memory leak in ipc_wwan_dellinkIOSM driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch sets needs_free_netdev to true when registersnetwork device, which makes netdev subsystem call free_netdev()automatically after unregister_netdevice().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix panic on frag_list with mixed head alloc typesSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat whensplitting gso_size mangled skb having linear-headed frag_list"), it isallowed to change gso_size of a GRO packet. However, that commit assumesthat "checking the first list_skb member suffices; i.e if either of thelist_skb members have non head_frag head, then the first one has too".It turns out this assumption does not hold. We've seen BUG_ON being hitin skb_segment when skbs on the frag_list had differing head_frag withthe vmxnet3 driver. This happens because __netdev_alloc_skb and__napi_alloc_skb can return a skb that is page backed or kmalloceddepending on the requested size. As the result, the last small skb inthe GRO packet can be kmalloced.There are three different locations where this can be fixed:(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list.(3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down.This patch implements (3). To limit the performance impact inskb_segment, the list is walked only for skbs with SKB_GSO_DODGY setthat have gso_size changed. Normal paths thus will not hit it.We could check only the last skb but since we need to walk the wholelist anyway, let's stay on the safe side.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix wrong reg type conversion in release_reference()Some helper functions will allocate memory. To avoid memory leaks, theverifier requires the eBPF program to release these memories by callingthe corresponding helper functions.When a resource is released, all pointer registers corresponding to theresource should be invalidated. The verifier use release_references() todo this job, by apply __mark_reg_unknown() to each relevant register.It will give these registers the type of SCALAR_VALUE. A register thatwill contain a pointer value at runtime, but of type SCALAR_VALUE, whichmay allow the unprivileged user to get a kernel pointer by storing thisregister into a map.Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate thisproblem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILEWhen using bpftool to pin {PROG, MAP, LINK} without FILE,segmentation fault will occur. The reson is that the lackof FILE will cause strlen to trigger NULL pointer dereference.The corresponding stacktrace is shown below:do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereferenceFix it by adding validation to the common process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49878 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, verifier: Fix memory leak in array reallocation for stack stateIf an error (NULL) is returned by krealloc(), callers of realloc_array()were setting their allocation pointers to NULL, but on error krealloc()does not touch the original allocation. This would result in a memoryresource leak. Instead, free the old allocation on the error handlingpath.The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix tree mod log mishandling of reallocated nodesWe have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n);This occurs because we replay the nodes in order that they happened, andwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,starting at 0. 'n' here is the number of items in this block, which inthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.The actual root cause of this was that we were replaying operations fora block that shouldn't have been replayed. Consider the followingsequence of events1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots.3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node.4. We modify a new root, and re-allocate the above node to the root node of this other root.The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8>From here the bug is triggered by the following steps1. Call btrfs_get_old_root() on the new_root.2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0.3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE.4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fscrypt: stop using keyrings subsystem for fscrypt_master_keyThe approach of fs/crypto/ internally managing the fscrypt_master_keystructs as the payloads of "struct key" objects contained in a"struct key" keyring has outlived its usefulness. The original idea wasto simplify the code by reusing code from the keyrings subsystem.However, several issues have arisen that can't easily be resolved:- When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free.- When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore.- More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped.- Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done.The fix for all these issues is to change the implementation to what Ishould have done originally: don't use the keyrings subsystem to keeptrack of the filesystem's fscrypt_master_key structs. Instead, juststore them in a regular kernel data structure, and rework the referencecounting, locking, and lifetime accordingly. Retain support forRCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()with fscrypt_sb_delete(), which releases the keys synchronously and runsa bit earlier during unmount, so that block devices are still available.A side effect of this patch is that neither the master keys themselvesnor the filesystem keyrings will be listed in /proc/keys anymore.("Master key users" and the master key users keyrings will still belisted.) However, this was mostly an implementation detail, and it wasintended just for debugging purposes. I don't know of anyone using it.This patch does *not* change how "master key users" (->mk_users) works;that still uses the keyrings subsystem. That is still needed for keyquotas, and changing that isn't necessary to solve the issues listedabove. If we decide to change that too, it would be a separate patch.I've marked this as fixing the original commit that added the fscryptkeyring, but as noted above the most important issue that this patchfixes wasn't introduced until the addition of inline encryption support.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: Fix kmemleak in blk_mq_init_allocated_queueThere is a kmemleak caused by modprobe null_blk.kounreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0That is because q->ma_ops is set to NULL before blk_release_queue iscalled.blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q);[1]: blk_mq_alloc_and_init_hctx failed at i != 0.[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list andwill be cleaned up in blk_mq_release.[3]: q->nr_hw_queues is 0.[4]: Set q->mq_ops to NULL.[5]: queue_is_mq returns false due to [4]. And blk_mq_releasewill not be called. The hctxs in q->unused_hctx_list are leaked.To fix it, call blk_release_queue in exception path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49903 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix WARNING in ip6_route_net_exit_late()During the initialization of ip6_route_net_init_late(), if fileipv6_route or rt6_stats fails to be created, the initialization issuccessful by default. Therefore, the ipv6_route or rt6_stats filedoesn't be found during the remove in ip6_route_net_exit_late(). Itwill cause WRNING.The following is the stack information:name 'rt6_stats'WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460PKRU: 55555554Call Trace:ops_exit_list+0xb0/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mdio: fix undefined behavior in bit shift for __mdiobus_registerShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: enforce documented limit to prevent allocating huge memoryDaniel Xu reported that the hash:net,iface type of the ipset subsystem doesnot limit adding the same network with different interfaces to a set, whichcan lead to huge memory usage or allocation failure.The quick reproducer is$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; doneThe backtrace when vmalloc fails: [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages <...> [Tue Oct 25 00:13:08 2022] Call Trace: [Tue Oct 25 00:13:08 2022] [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60 [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180 [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20 [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90 [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710 <...>The fix is to enforce the limit documented in the ipset(8) manpage:> The internal restriction of the hash:net,iface set type is that the same> network prefix cannot be stored with more than 64 different interfaces> in a single set.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at find_parent_nodes()During backref walking, at find_parent_nodes(), if we are dealing with adata extent and we get an error while resolving the indirect backrefs, atresolve_indirect_refs(), or in the while loop that iterates over the refsin the direct refs rbtree, we end up leaking the inode lists attached tothe direct refs we have in the direct refs rbtree that were not yet addedto the refs ulist passed as argument to find_parent_nodes(). Since theywere not yet added to the refs ulist and prelim_release() does not freethe lists, on error the caller can only free the lists attached to therefs that were added to the refs ulist, all the remaining refs get theirinode lists never freed, therefore leaking their memory.Fix this by having prelim_release() always free any attached inode listto each ref found in the rbtree, and have find_parent_nodes() set theref's inode list to NULL once it transfers ownership of the inode listto a ref added to the refs ulist passed to find_parent_nodes().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at resolve_indirect_refs()During backref walking, at resolve_indirect_refs(), if we get an errorwe jump to the 'out' label and call ulist_free() on the 'parents' ulist,which frees all the elements in the ulist - however that does not freeany inode lists that may be attached to elements, through the 'aux' fieldof a ulist node, so we end up leaking lists if we have any attached tothe unodes.Fix this by calling free_leaf_list() instead of ulist_free() when we exitfrom resolve_indirect_refs(). The static function free_leaf_list() ismoved up for this to be possible and it's slightly simplified by removingunnecessary code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix WARNING in ip_vs_app_net_cleanup()During the initialization of ip_vs_app_net_init(), if file ip_vs_appfails to be created, the initialization is successful by default.Therefore, the ip_vs_app file doesn't be found during the remove inip_vs_app_net_cleanup(). It will cause WRNING.The following is the stack information:name 'ip_vs_app'WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460Call Trace:ops_exit_list+0x125/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: netlink notifier might race to release objectscommit release path is invoked via call_rcu and it runs lockless torelease the objects after rcu grace period. The netlink notifier handlermight win race to remove objects that the transaction context is stillreferencing from the commit release path.Call rcu_barrier() to ensure pending rcu callbacks run to completionif the list of transactions to be destroyed is not empty.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49921 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: Fix use after free in red_enqueue()We can't use "skb" again after passing it to qdisc_enqueue(). This isbasically identical to commit 2f09707d0c97 ("sch_sfb: Also store skblen before calling child enqueue").

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49926 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Fix possible memory leaks in dsa_loop_init()kmemleak reported memory leaks in dsa_loop_init():kmemleak: 12 new suspected memory leaksunreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ...There are two reasons for memleak in dsa_loop_init().First, fixed_phy_register() create and register phy_device:fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove()But fixed_phy_unregister() only calls phy_device_remove().So the memory allocated in phy_device_create() is leaked.Second, when mdio_driver_register() fail in dsa_loop_init(),it just returns and there is no cleanup for phydevs.Fix the problems by catching the error of mdio_driver_register()in dsa_loop_init(), then calling both fixed_phy_unregister() andphy_device_free() to release phydevs.Also add a function for phydevs cleanup to avoid duplacate.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/dma-resv: check if the new fence is really laterPreviously when we added a fence to a dma_resv object we alwaysassumed the the newer than all the existing fences.With Jason's work to add an UAPI to explicit export/import that's notnecessary the case any more. So without this check we would allowuserspace to force the kernel into an use after free error.Since the change is very small and defensive it's probably a goodidea to backport this to stable kernels as well just in case othersare using the dma_resv object in the same way.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a data-race around bpf_jit_limit.While reading bpf_jit_limit, it can be changed concurrently via sysctl,WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limitis long, so we need to add a paired READ_ONCE() to avoid load-tearing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pteIn MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the pagecache are installed in the ptes. But hugepage_add_new_anon_rmap is calledfor them mistakenly because they're not vm_shared. This will corrupt thepage->mapping used by page cache code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bootmem: remove the vmemmap pages from kmemleak in put_page_bootmemThe vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reusethe page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lantiq_xrx200: restore buffer if memory allocation failedIn a situation where memory allocation fails, an invalid buffer addressis stored. When this descriptor is used again, the system panics in thebuild_skb() function when accessing memory.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix locking in rxrpc's sendmsgFix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wait_for_tx_window*() and (b) indicating to higher callers whether we're return with the lock dropped. Note that this means recvmsg() will not block on this call whilst we're waiting. (3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the same call.Thinking on this some more, it might make sense to have different locks forsendmsg() and recvmsg(). There's probably no need to make recvmsg() waitfor sendmsg(). It does mean that recvmsg() can return MSG_EOR indicatingthat a call is dead before a sendmsg() to that call returns - but that cancurrently happen anyway.Without fix (2), something like the following can be induced: WARNING: bad unlock balance detected! 5.16.0-rc6-syzkaller #0 Not tainted ------------------------------------- syz-executor011/3597 is trying to release lock (&call->user_mutex) at: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 but there are no more locks to release! other info that might help us debug this: no locks held by syz-executor011/3597. ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline] __lock_release kernel/locking/lockdep.c:5306 [inline] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: fix stuck flows on cleanup due to pending workTo clear the flow table on flow table free, the following sequencenormally happens in order: 1) gc_step work is stopped to disable any further stats/del requests. 2) All flow table entries are set to teardown state. 3) Run gc_step which will queue HW del work for each flow table entry. 4) Waiting for the above del work to finish (flush). 5) Run gc_step again, deleting all entries from the flow table. 6) Flow table is freed.But if a flow table entry already has pending HW stats or HW add workstep 3 will not queue HW del work (it will be skipped), step 4 will waitfor the pending add/stats to finish, and step 5 will queue HW del workwhich might execute after freeing of the flow table.To fix the above, this patch flushes the pending work, then it sets theteardown flag to all flows in the flowtable and it forces a garbagecollector run to queue work to remove the flows from hardware, then itflushes this new pending work and (finally) it forces another garbagecollector run to remove the entry from the software flowtable.Stack trace:[47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460[47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704[47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2[47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)[47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table][47773.889727] Call Trace:[47773.890214] dump_stack+0xbb/0x107[47773.890818] print_address_description.constprop.0+0x18/0x140[47773.892990] kasan_report.cold+0x7c/0xd8[47773.894459] kasan_check_range+0x145/0x1a0[47773.895174] down_read+0x99/0x460[47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table][47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table][47773.913372] process_one_work+0x8ac/0x14e0[47773.921325][47773.921325] Allocated by task 592159:[47773.922031] kasan_save_stack+0x1b/0x40[47773.922730] __kasan_kmalloc+0x7a/0x90[47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct][47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct][47773.925207] tcf_action_init_1+0x45b/0x700[47773.925987] tcf_action_init+0x453/0x6b0[47773.926692] tcf_exts_validate+0x3d0/0x600[47773.927419] fl_change+0x757/0x4a51 [cls_flower][47773.928227] tc_new_tfilter+0x89a/0x2070[47773.936652][47773.936652] Freed by task 543704:[47773.937303] kasan_save_stack+0x1b/0x40[47773.938039] kasan_set_track+0x1c/0x30[47773.938731] kasan_set_free_info+0x20/0x30[47773.939467] __kasan_slab_free+0xe7/0x120[47773.940194] slab_free_freelist_hook+0x86/0x190[47773.941038] kfree+0xce/0x3a0[47773.941644] tcf_ct_flow_table_cleanup_workOriginal patch description and stack trace by Paul Blakey.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_tproxy: restrict to prerouting hookTPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.This fixes a crash (null dereference) when using tproxy from e.g. output.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READYOnly set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered.Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev andldev->pf[MLX5_LAG_P1].dev have valid pointers whenMLX5_LAG_FLAG_NDEVS_READY is set.The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY andclearing it. Setting it is done wrongly when bothldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set;clearing it is done right when either of ldev->pf[i].netdev is cleared.Consider the following scenario:1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in MLX5_LAG_FLAG_NDEVS_READY is set.3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY remains set.Further execution of mlx5_do_bond() will result in null pointerdereference when calling mlx5_lag_is_multipath()This patch fixes the following call trace actually encountered:[ 1293.475195] BUG: kernel NULL pointer dereference, address: 00000000000009a8[ 1293.478756] #PF: supervisor read access in kernel mode[ 1293.481320] #PF: error_code(0x0000) - not-present page[ 1293.483686] PGD 0 P4D 0[ 1293.484434] Oops: 0000 [#1] SMP PTI[ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1[ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core][ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core][ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8[ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202[ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000[ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000[ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c[ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0[ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858[ 1293.508753] FS: 0000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000[ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0[ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: xsk: prohibit usage of non-balanced queue idFix the following scenario:1. ethtool -L $IFACE rx 8 tx 962. xdpsock -q 10 -t -zAbove refers to a case where user would like to attach XSK socket intxonly mode at a queue id that does not have a corresponding Rx queue.At this moment ice's XSK logic is tightly bound to act on a "queue pair",e.g. both Tx and Rx queues at a given queue id are disabled/enabled andboth of them will get XSK pool assigned, which is broken for the presentedqueue configuration. This results in the splat included at the bottom,which is basically an OOB access to Rx ring array.To fix this, allow using the ids only in scope of "combined" queuesreported by ethtool. However, logic should be rewritten to allow suchconfigurations later on, which would end up as a complete rewrite of thecontrol path, so let us go with this temporary fix.[420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082[420160.566359] #PF: supervisor read access in kernel mode[420160.572657] #PF: error_code(0x0000) - not-present page[420160.579002] PGD 0 P4D 0[420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI[420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10[420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice][420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85[420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282[420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8[420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000[420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000[420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a[420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828[420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000[420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[420160.711783] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0[420160.721399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[420160.740707] PKRU: 55555554[420160.745960] Call Trace:[420160.750962] [420160.755597] ? kmalloc_large_node+0x79/0x90[420160.762703] ? __kmalloc_node+0x3f5/0x4b0[420160.769341] xp_assign_dev+0xfd/0x210[420160.775661] ? shmem_file_read_iter+0x29a/0x420[420160.782896] xsk_bind+0x152/0x490[420160.788943] __sys_bind+0xd0/0x100[420160.795097] ? exit_to_user_mode_prepare+0x20/0x120[420160.802801] __x64_sys_bind+0x16/0x20[420160.809298] do_syscall_64+0x38/0x90[420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd[420160.823731] RIP: 0033:0x7fa86a0dd2fb[420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48[420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031[420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb[420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003[420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000[420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0[420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000[420160.919817] [420160.925659] Modules linked in: ice(OE) af_packet binfmt_misc---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix refcount leak in __xfrm_policy_check()The issue happens on an error path in __xfrm_policy_check(). When thefetching process of the object `pols[1]` fails, the function simplyreturns 0, forgetting to decrement the reference count of `pols[0]`,which is incremented earlier by either xfrm_sk_policy_lookup() orxfrm_policy_lookup(). This may result in memory leaks.Fix it by decreasing the reference count of `pols[0]` in that path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware bootIt is not yet clear, but it is possible to create a firmware so brokenthat it will send a reply message before a FW_READY message (it is notyet clear if FW_READY will arrive later).Since the reply_data is allocated only after the FW_READY message, thiswill lead to a NULL pointer dereference if not filtered out.The issue was reported with IPC4 firmware but the same condition is presentfor IPC3.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware bootIt is not yet clear, but it is possible to create a firmware so brokenthat it will send a reply message before a FW_READY message (it is notyet clear if FW_READY will arrive later).Since the reply_data is allocated only after the FW_READY message, thiswill lead to a NULL pointer dereference if not filtered out.The issue was reported with IPC4 firmware but the same condition is presentfor IPC3.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50042 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: genl: fix error path memory leak in policy dumpingIf construction of the array of policies fails when recordingnon-first policy we need to unwind.netlink_policy_dump_add_policy() itself also needs fixing asit currently gives up on error without recording the allocatedpointer in the pstate pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50043 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix potential refcount leak in ndisc_router_discovery()The issue happens on specific paths in the function. After both theobject `rt` and `neigh` are grabbed successfully, when `lifetime` isnonzero but the metric needs change, the function just deletes theroute and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`again if above conditions hold. The function simply overwrite `neigh`if succeeds or returns if fails, without decreasing the referencecount of previous `neigh`. This may result in memory leaks.Fix it by decrementing the reference count of `neigh` in place.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: start MHI channel after endpoit creationMHI channel may generates event/interrupt right after enabling.It may leads to 2 race conditions issues.1)Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return;Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed atthis moment. In this situation qrtr-ns will be unable to enumerateservices in device.---------------------------------------------------------------2)Such event may come at the moment after dev_set_drvdata() andbefore qrtr_endpoint_register(). In this case kernel will panic withaccessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd);Because endpoint is not created yet.--------------------------------------------------------------So move mhi_prepare_for_transfer_autoqueue after endpoint creationto fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: possible module reference underflow in error pathdst->ops is set on when nft_expr_clone() fails, but module refcount hasnot been bumped yet, therefore nft_expr_destroy() leads to modulereference underflow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50050 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()snprintf() returns the would-be-filled size when the string overflowsthe given buffer size, hence using this value may result in the bufferoverflow (although it's unrealistic).This patch replaces with a safer version, scnprintf() for paperingover such a potential issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:BPF: Fix potential bad pointer dereference in bpf_sys_bpf()The bpf_sys_bpf() helper function allows an eBPF program to load anothereBPF program from within the kernel. In this case the argument unionbpf_attr pointer (as well as the insns and license pointers inside) is akernel address instead of a userspace address (which is the case of ausual bpf() syscall). To make the memory copying process in the syscallwork in both cases, bpfptr_t was introduced to wrap around the pointerand distinguish its origin. Specifically, when copying memory contentsfrom a bpfptr_t, a copy_from_user() is performed in case of a userspaceaddress and a memcpy() is performed for a kernel address.This can lead to problems because the in-kernel pointer is never checkedfor validity. The problem happens when an eBPF syscall program tries tocall bpf_sys_bpf() to load a program but provides a bad insns pointer --say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()which would then call bpf_prog_load() to load the program.bpf_prog_load() is responsible for copying the eBPF instructions to thenewly allocated memory for the program; it creates a kernel bpfptr_t forinsns and invokes copy_from_bpfptr(). Internally, all bpfptr_toperations are backed by the corresponding sockptr_t operations, whichperforms direct memcpy() on kernel pointers for copy_from/strncpy_fromoperations. Therefore, the code is always happy to dereference the badpointer to trigger a un-handle-able page fault and in turn an oops.However, this is not supposed to happen because at that point the eBPFprogram is already verified and should not cause a memory error.Sample KASAN trace:[ 25.685056][ T228] ==================================================================[ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30[ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228[ 25.686732][ T228][ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7[ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014[ 25.687991][ T228] Call Trace:[ 25.688223][ T228] [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e[ 25.688747][ T228] print_report+0xea/0x200[ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.689401][ T228] ? _printk+0x54/0x6e[ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0[ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.690412][ T228] kasan_report+0xb5/0xe0[ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0[ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.691734][ T228] memcpy+0x25/0x60[ 25.692000][ T228] copy_from_bpfptr+0x21/0x30[ 25.692328][ T228] bpf_prog_load+0x604/0x9e0[ 25.692653][ T228] ? cap_capable+0xb4/0xe0[ 25.692956][ T228] ? security_capable+0x4f/0x70[ 25.693324][ T228] __sys_bpf+0x3af/0x580[ 25.693635][ T228] bpf_sys_bpf+0x45/0x240[ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd[ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0[ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0[ 25.695144][ T228] bpf_prog_test_run+0x172/0x190[ 25.695487][ T228] __sys_bpf+0x2c5/0x580[ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50[ 25.696084][ T228] do_syscall_64+0x60/0x90[ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60[ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0[ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40[ 25.697586][ T228] ? do_syscall_64+0x6e/0x90[ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 25.698312][ T228] RIP: 0033:0x7f6d543fb759[ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50070 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: do not queue data on closed subflowsDipanjan reported a syzbot splat at close time:WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153Modules linked in: uio_ivshmem(OE) uio(E)CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE5.19.0-rc6-g2eae0556bb9d #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.13.0-1ubuntu1.1 04/01/2014Workqueue: events mptcp_workerRIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0be9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4dRSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0Call Trace: __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067 sk_destruct+0xbd/0xe0 net/core/sock.c:2112 __sk_free+0xef/0x3d0 net/core/sock.c:2123 sk_free+0x78/0xa0 net/core/sock.c:2134 sock_put include/net/sock.h:1927 [inline] __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289 worker_thread+0x623/0x1070 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 The root cause of the problem is that an mptcp-level (re)transmit canrace with mptcp_close() and the packet scheduler checks the subflowstate before acquiring the socket lock: we can try to (re)transmit onan already closed ssk.Fix the issue checking again the subflow socket status under thesubflow socket lock protection. Additionally add the missing checkfor the fallback-to-tcp case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: move subflow cleanup in mptcp_destroy_common()If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATEeBPF program, the MPTCP protocol ends-up leaking all the subflows:the related cleanup happens in __mptcp_destroy_sock() that is notinvoked in such code path.Address the issue moving the subflow sockets cleanup in themptcp_destroy_common() helper, which is invoked in every msk cleanuppath.Additionally get rid of the intermediate list_splice_init step, whichis an unneeded relic from the past.The issue is present since before the reported root cause commit, butany attempt to backport the fix before that hash will require a completerewrite.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: add overflow check in register_shm_helper()With special lengths supplied by user space, register_shm_helper() hasan integer overflow when calculating the number of pages covered by asupplied user space memory region.This causes internal_get_user_pages_fast() a helper function ofpin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114Fix this by adding an an explicit call to access_ok() intee_shm_register_user_buf() to catch an invalid user space addressearly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix warning in ext4_iomap_begin as race between bmap and writeWe got issue as follows:------------[ cut here ]------------WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0RIP: 0010:ext4_iomap_begin+0x182/0x5d0RSP: 0018:ffff88812460fa08 EFLAGS: 00010293RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20fR10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691eeFS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Above issue may happen as follows: bmap writebmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_onTo solved above issue hold inode lock in ext4_bamp.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: don't allow the same type rq_qos add more than onceIn our test of iocost, we encountered some list add/del corruptions ofinner_walk list in ioc_timer_fn.The reason can be described as follows:cpu 0 cpu 1ioc_qos_write ioc_qos_writeioc = q_to_ioc(queue);if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ...}When the io.cost.qos file is written by two cpus concurrently, rq_qos maybe added to one disk twice. In that case, there will be two iocs enabledand running on one disk. They own different iocgs on their active list. Inthe ioc_timer_fn function, because of the iocgs from two iocs have thesame root iocg, the root iocg's walk_list may be overwritten by each otherand this leads to list add/del corruptions in building or destroying theinner_walk list.And so far, the blk-rq-qos framework works in case that one instance forone type rq_qos per queue by default. This patch make this explicit andalso fix the crash above.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure pages are unlocked on cow_file_range() failureThere is a hung_task report on zoned btrfs like below.https://github.com/naota/linux/issues/59 [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] While we debug the issue, we found running fstests generic/551 on 5GBnon-zoned null_blk device in the emulated zoned mode also had asimilar hung issue.Also, we can reproduce the same symptom with an error injectedcow_file_range() setup.The hang occurs when cow_file_range() fails in the middle ofallocation. cow_file_range() called from do_allocation_zoned() cansplit the give region ([start, end]) for allocation depending oncurrent block group usages. When btrfs can allocate bytes for one partof the split regions but fails for the other region (e.g. because of-ENOSPC), we return the error leaving the pages in the succeeded regionslocked. Technically, this occurs only when @unlock == 0. Otherwise, weunlock the pages in an allocated region after creating an orderedextent.Considering the callers of cow_file_range(unlock=0) won't write outthe pages, we can unlock the pages on error exit fromcow_file_range(). So, we can ensure all the pages except @locked_pageare unlocked on error case.In summary, cow_file_range now behaves like this:- page_started == 1 (return value) - All the pages are unlocked. IO is started.- unlock == 1 - All the pages except @locked_page are unlocked in any case- unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @locked_page are unlocked

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_sizeOn zoned filesystem, data write out is limited by max_zone_append_size,and a large ordered extent is split according the size of a bio. OTOH,the number of extents to be written is calculated usingBTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve themetadata bytes to update and/or create the metadata items.The metadata reservation is done at e.g, btrfs_buffered_write() and thenreleased according to the estimation changes. Thus, if the number of extentincreases massively, the reserved metadata can run out.The increase of the number of extents easily occurs on zoned filesystemif BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes thefollowing warning on a small RAM environment with disabling metadataover-commit (in the following patch).[75721.498492] ------------[ cut here ]------------[75721.505624] BTRFS: block rsv 1 returned -28[75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs][75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109[75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021[75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs][75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs][75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286[75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000[75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e[75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7[75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28[75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a[75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000[75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0[75721.730499] Call Trace:[75721.735166] [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs][75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs][75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs][75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs][75721.769520] ? push_leaf_left+0x420/0x620 [btrfs][75721.776431] ? memcpy+0x4e/0x60[75721.781931] split_leaf+0x433/0x12d0 [btrfs][75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs][75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs][75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs][75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs][75721.818300] ? lock_downgrade+0x7c0/0x7c0[75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs][75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs][75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs][75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs][75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs][75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs][75721.869313] ? rcu_read_lock_sched_held+0x16/0x80[75721.876085] ? lock_release+0x552/0xf80[75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs][75721.888886] ? __kasan_check_write+0x14/0x20[75721.895152] ? do_raw_read_unlock+0x44/0x80[75721.901323] ? _raw_write_lock_irq+0x60/0x80[75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs][75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs][75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs][75721.929166] ? _raw_write_unlock+0x23/0x40[75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs][75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs][75721.949906] ? try_to_wake_up+0x30/0x14a0[75721.955700] ? btrfs_unlink_subvol+0xda0/0xda0 [btrfs][75721.962661] ? rcu---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50091 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:locking/csd_lock: Change csdlock_debug from early_param to __setupThe csdlock_debug kernel-boot parameter is parsed by theearly_param() function csdlock_debug(). If set, csdlock_debug()invokes static_branch_enable() to enable csd_lock_wait feature, whichtriggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y andCONFIG_SPARSEMEM_VMEMMAP=n.With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called instatic_key_enable() and returns NULL, resulting in a NULL dereferencebecause mem_section is initialized only later in sparse_init().This is also a problem for powerpc because early_param() functionsare invoked earlier than jump_label_init(), also resulting instatic_key_enable() failures. These failures cause the warning "statickey 'xxx' used before call to jump_label_init()".Thus, early_param is too early for csd_lock_wait to runstatic_branch_enable(), so changes it to __setup to fix these.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/kprobes: Update kcb status flag after singlesteppingFix kprobes to update kcb (kprobes control block) status flag toKPROBE_HIT_SSDONE even if the kp->post_handler is not set.This bug may cause a kernel panic if another INT3 user runs rightafter kprobes because kprobe_int3_handler() misunderstands theINT3 is kprobe's single stepping INT3.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: 9p: fix refcount leak in p9_read_work() error handlingp9_req_put need to be called when m->rreq->rc.sdata is NULL to avoidtemporary refcount leak.[Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: revisit driver bind/unbind and callbacksIn the SoundWire probe, we store a pointer from the driver ops intothe 'slave' structure. This can lead to kernel oopses when unbindingcodec drivers, e.g. with the following sequence to remove machinedriver and codec driver./sbin/modprobe -r snd_soc_sof_sdw/sbin/modprobe -r snd_soc_rt711The full details can be found in the BugLink below, for reference thetwo following examples show different cases of driver ops/callbacksbeing invoked after the driver .remove().kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]kernel: RIP: 0010:mutex_lock+0x19/0x30kernel: Call Trace:kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]kernel: ? newidle_balance+0x26a/0x400kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]kernel: BUG: unable to handle page fault for address: ffffffffc07654c8kernel: Workqueue: pm pm_runtime_workkernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]kernel: Call Trace:kernel: kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd]kernel: ? dpm_sysfs_remove+0x60/0x60This was not detected earlier in Intel tests since the tests firstremove the parent PCI device and shut down the bus. The sequenceabove is a corner case which keeps the bus operational but without adriver bound.While trying to solve this kernel oopses, it became clear that theexisting SoundWire bus does not deal well with the unbind case.Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields")added a 'probed' status variable and a 'probe_complete'struct completion. This status is however not reset on remove andlikewise the 'probe complete' is not re-initialized, so thebind/unbind/bind test cases would fail. The timeout used before the'update_status' callback was also a bad idea in hindsight, thereshould really be no timing assumption as to if and when a driver isbound to a device.An initial draft was based on device_lock() and device_unlock() wastested. This proved too complicated, with deadlocks created during thesuspend-resume sequences, which also use the same device_lock/unlock()as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOScaused spurious resumes and the use of device_lock() caused hangsduring suspend. After multiple weeks or testing and painfulreverse-engineering of deadlocks on different devices, we looked foralternatives that did not interfere with the device core.A bus notifier was used successfully to keep track of DRIVER_BOUND andDRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,but it can still be defeated with a theoretical corner case where thememory is freed by a .remove while the callback is in use. Thenotifier only helps make sure the driver callbacks are valid, but notthat the memory allocated in probe remains valid while the callbacksare invoked.This patch suggests the introduction of a new 'sdw_dev_lock' mutexprotecting probe/remove and all driver callbacks. Since this mutex is'local' to SoundWire only, it does not interfere with existing locksand does not create deadlocks. In addition, this patch removes the'probe_complete' completion, instead we directly invoke the'update_status' from the probe routine. That removes any sort oftiming dependency and a much better support for the device/drivermodel, the driver could be bound before the bus started, or eons afterthe bus started and the hardware would be properly initialized in allcases.BugLink: https://github.com/thesofproject/linux/is---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50159 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: check previous kernel's ima-kexec-buffer against memory boundsPresently ima_get_kexec_buffer() doesn't check if the previous kernel'sima-kexec-buffer lies outside the addressable memory range. This can resultin a kernel panic if the new kernel is booted with 'mem=X' arg and theima-kexec-buffer was allocated beyond that range by the previous kernel.The panic is usually of the form below:$ sudo kexec --initrd initrd vmlinux --append='mem=16G' BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---Fix this issue by checking returned PFN range of previous kernel'sima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix incorrect dev_tracker usageWhile investigating a separate rose issue [1], and enablingCONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]An ax25_dev can be used by one (or many) struct ax25_cb.We thus need different dev_tracker, one per struct ax25_cb.After this patch is applied, we are able to focus on rose.[1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/[2][ 205.798723] reference already released.[ 205.798732] allocated in:[ 205.798734] ax25_bind+0x1a2/0x230 [ax25][ 205.798747] __sys_bind+0xea/0x110[ 205.798753] __x64_sys_bind+0x18/0x20[ 205.798758] do_syscall_64+0x5c/0x80[ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 205.798768] freed in:[ 205.798770] ax25_release+0x115/0x370 [ax25][ 205.798778] __sock_release+0x42/0xb0[ 205.798782] sock_close+0x15/0x20[ 205.798785] __fput+0x9f/0x260[ 205.798789] ____fput+0xe/0x10[ 205.798792] task_work_run+0x64/0xa0[ 205.798798] exit_to_user_mode_prepare+0x18b/0x190[ 205.798804] syscall_exit_to_user_mode+0x26/0x40[ 205.798808] do_syscall_64+0x69/0x80[ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 205.798827] ------------[ cut here ]------------[ 205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81[ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video[ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25][ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3[ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020[ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81[ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e[ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286[ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000[ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff[ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618[ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0[ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001[ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000[ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0[ 205.799033] Call Trace:[ 205.799035] [ 205.799038] ? ax25_dev_device_down+0xd9/---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: When HCI work queue is drained, only queue chained workThe HCI command, event, and data packet processing workqueue is drainedto avoid deadlock in commit76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").There is another delayed work, which will queue command to this drainedworkqueue. Which results in the following error report:Bluetooth: hci2: command 0x040f tx timeoutWARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140Workqueue: events hci_cmd_timeoutRIP: 0010:__queue_work+0xdad/0x1140RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue thetimeout workqueue while command workqueue is draining.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix potential 32-bit overflow when accessing ARRAY map elementIf BPF array map is bigger than 4GB, element pointer calculation canoverflow because both index and elem_size are u32. Fix this everywhereby forcing 64-bit multiplication. Extract this formula into separatesmall helper and use it consistently in various places.Speculative-preventing formula utilizing index_mask trick is left as is,but explicit u64 casts are added in both places.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: avoid kernel hung in hinic_get_stats64()When using hinic device as a bond slave device, and reading device statsof master bond device, the kernel may hung.The kernel panic calltrace as follows:Kernel panic - not syncing: softlockup: hung tasksCall trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324When getting device stats from bond, kernel will call bond_get_stats().It first holds the spinlock bond->stats_lock, and then callhinic_get_stats64() to collect hinic device's stats.However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` toprotect its critical section, which may schedule current task out.And if system is under high pressure, the task cannot be woken upimmediately, which eventually triggers kernel hung panic.Since previous patch has replaced hinic_dev.tx_stats/rx_stats with localvariable in hinic_get_stats64(), there is nothing need to be protectedby lock, so just removing down()/up() is ok.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50177 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcutorture: Fix ksoftirqd boosting timing and iterationThe RCU priority boosting can fail in two situations:1) If (nr_cpus= > maxcpus=), which means if the total number of CPUsis higher than those brought online at boot, then torture_onoff() maylater bring up CPUs that weren't online on boot. Now since rcutortureinitialization only boosts the ksoftirqds of the CPUs that have beenset online on boot, the CPUs later set online by torture_onoff won'tbenefit from the boost, making RCU priority boosting fail.2) The ksoftirqd kthreads are boosted after the creation ofrcu_torture_boost() kthreads, which opens a window large enough for thesercu_torture_boost() kthreads to wait (despite running at FIFO priority)for ksoftirqds that are still running at SCHED_NORMAL priority.The issues can trigger for example with: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Modules linked in: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1 [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: De-offloading 8 [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Call Trace: [ 37.295049] [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] Fix this with boosting the ksoftirqds kthreads from the boostinghotplug callback itself and before the boosting kthreads are created.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Align upwards buffer sizeThe hardware can support any image size WxH,with arbitrary W (image width) and H (image height) dimensions.Align upwards buffer size for both encoder and decoder.and leave the picture resolution unchanged.For decoder, the risk of memory out of bounds can be avoided.For both encoder and decoder, the driver will lift the limitation ofresolution alignment.For example, the decoder can support jpeg whose resolution is 227x149the encoder can support nv12 1080P, won't change it to 1920x1072.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_initof_graph_get_remote_node() returns remote device nodepointer withrefcount incremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: qcom: replace gcc PXO with pxo_board fixed clockReplace gcc PXO phandle to pxo_board fixed clock declared in the dts.gcc driver doesn't provide PXO_SRC as it's a fixed-clock. This cause akernel panic if any driver actually try to use it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Clear the connection field properlycoresight devices track their connections (output connections) andhold a reference to the fwnode. When a device goes away, we walk throughthe devices on the coresight bus and make sure that the referencesare dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data()b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match().However, the coresight_remove_match() doesn't clear the fwnode field,after dropping the reference, this causes use-after-free andadditional refcount drops on the fwnode.e.g., if we have two devices, A and B, with a connection, A -> B.If we remove B first, B would clear the reference on B, from Avia coresight_remove_match(). But when A is removed, it still hasa connection with fwnode still pointing to B. Thus it tries to dropsthe reference in coresight_release_platform_data(), raising the bellslike :[ 91.990153] ------------[ cut here ]------------[ 91.990163] refcount_t: addition on 0; use-after-free.[ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144[ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug][ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53[ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019[ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 91.990454] pc : refcount_warn_saturate+0xa0/0x144[ 91.990476] lr : refcount_warn_saturate+0xa0/0x144[ 91.990496] sp : ffff80000c843640[ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8[ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8[ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2[ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40[ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0[ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375[ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28[ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572[ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027[ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00[ 91.991000] Call trace:[ 91.991012] refcount_warn_saturate+0xa0/0x144[ 91.991034] kobject_get+0xac/0xb0[ 91.991055] of_node_get+0x2c/0x40[ 91.991076] of_fwnode_get+0x40/0x60[ 91.991094] fwnode_handle_get+0x3c/0x60[ 91.991116] fwnode_get_nth_parent+0xf4/0x110[ 91.991137] fwnode_full_name_string+0x48/0xc0[ 91.991158] device_node_string+0x41c/0x530[ 91.991178] pointer+0x320/0x3ec[ 91.991198] vsnprintf+0x23c/0x750[ 91.991217] vprintk_store+0x104/0x4b0[ 91.991238] vprintk_emit+0x8c/0x360[ 91.991257] vprintk_default+0x44/0x50[ 91.991276] vprintk+0xcc/0xf0[ 91.991295] _printk+0x68/0x90[ 91.991315] of_node_release+0x13c/0x14c[ 91.991334] kobject_put+0x98/0x114[ 91.991354] of_node_put+0x24/0x34[ 91.991372] of_fwnode_put+0x40/0x5c[ 91.991390] fwnode_handle_put+0x38/0x50[ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight][ 91.991472] coresight_unregister+0x64/0xcc [coresight][ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x][ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x][ 91.991598] amba_remove+0x3c/0x19c---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix KASAN use-after-free Read in compute_effective_progsSyzbot found a Use After Free bug in compute_effective_progs().The reproducer creates a number of BPF links, and causes a faultinjected alloc to fail, while calling bpf_link_detach on them.Link detach triggers the link to be freed by bpf_link_free(),which calls __cgroup_bpf_detach() and update_effective_progs().If the memory allocation in this function fails, the function restoresthe pointer to the bpf_cgroup_link on the cgroup list, but the memorygets freed just after it returns. After this, every subsequent call toupdate_effective_progs() causes this already deallocated pointer to bedereferenced in prog_list_length(), and triggers KASAN UAF error.To fix this issue don't preserve the pointer to the prog or link in thelist, but remove it and replace it with a dummy prog without shrinkingthe table. The subsequent call to __cgroup_bpf_detach() or__cgroup_bpf_detach() will correct it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Treat NX as a valid SPTE bit for NPTTreat the NX bit as valid when using NPT, as KVM will set the NX bit whenthe NX huge page mitigation is enabled (mindblowing) and trigger the WARNthat fires on reserved SPTE bits being set.KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:Refuse to load kvm_amd if NX support is not available") for exactly thisreason, but apparently it never occurred to anyone to actually test NPTwith the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv:uprobe fix SR_SPIE set/clear handlingIn riscv the process of uprobe going to clear spie before execthe origin insn,and set spie after that.But When access the pagewhich origin insn has been placed a page fault may happen andirq was disabled in arch_uprobe_pre_xol function,It cause a WARNas follows.There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.We can just remove it.[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work[ 31.684929] preempt_count: 0, expected: 0[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G[ 31.686542] Hardware name: riscv-virtio,qemu (DT)[ 31.686797] Call Trace:[ 31.687053] [] dump_backtrace+0x30/0x38[ 31.687699] [] show_stack+0x40/0x4c[ 31.688141] [] dump_stack_lvl+0x44/0x5c[ 31.688396] [] dump_stack+0x18/0x20[ 31.688653] [] __might_resched+0x114/0x122[ 31.688948] [] __might_sleep+0x50/0x7a[ 31.689435] [] down_read+0x30/0x130[ 31.689728] [] do_page_fault+0x166/x446[ 31.689997] [] ret_from_exception+0x0/0xc

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: Lax permissions set by the Apache Portable Runtime library on Unix platforms would allow local users read access to named shared memory segments, potentially revealing sensitive application data. This issue does not affect non-Unix platforms, or builds with APR_USE_SHMEM_SHMGET=1 (apr.h)Users are recommended to upgrade to APR version 1.7.5, which fixes this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libapr1 > 0-0 (version in image is 1.6.3-150000.3.6.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm: Don't unref the same fb many times by mistake due to deadlock handlingIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()we proceed to unref the fb and then retry the whole thing from the top.But we forget to reset the fb pointer back to NULL, and so if we thenget another error during the retry, before the fb lookup, we proceedthe unref the same fb again without having gotten another reference.The end result is that the fb will (eventually) end up being freedwhile it's still in use.Reset fb to NULL once we've unreffed it to avoid doing it againuntil we've done another fb lookup.This turned out to be pretty easy to hit on a DG2 when doing asyncflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom Isaw that drm_closefb() simply got stuck in a busy loop while walkingthe framebuffer list. Fortunately I was able to convince it to oopsinstead, and from there it was easier to track down the culprit.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOThe SC16IS7XX IC supports a burst mode to access the FIFOs where theinitial register address is sent ($00), followed by all the FIFO datawithout having to resend the register address each time. In this mode, theIC doesn't increment the register address for each R/W byte.The regmap_raw_read() and regmap_raw_write() are functions which canperform IO over multiple registers. They are currently used to read/writefrom/to the FIFO, and although they operate correctly in this burst mode onthe SPI bus, they would corrupt the regmap cache if it was not disabledmanually. The reason is that when the R/W size is more than 1 byte, thesefunctions assume that the register address is incremented and handle thecache accordingly.Convert FIFO R/W functions to use the regmap _noinc_ versions in order toremove the manual cache control which was a workaround when using the_raw_ versions. FIFO registers are properly declared as volatile socache will not be used/updated for FIFO accesses.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PM: sleep: Fix possible deadlocks in core system-wide PM codeIt is reported that in low-memory situations the system-wide resume corecode deadlocks, because async_schedule_dev() executes its argumentfunction synchronously if it cannot allocate memory (and not only inthat case) and that function attempts to acquire a mutex that is alreadyheld. Executing the argument function synchronously from withindpm_async_fn() may also be problematic for ordering reasons (it maycause a consumer device's resume callback to be invoked before arequisite supplier device's one, for example).Address this by changing the code in question to useasync_schedule_dev_nocall() for scheduling the asynchronousexecution of device suspend and resume functions and to directlyrun them synchronously if async_schedule_dev_nocall() returns false.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix possible store tearing in neigh_periodic_work()While looking at a related syzbot report involving neigh_periodic_work(),I found that I forgot to add an annotation when deleting anRCU protected item from a list.Readers use rcu_deference(*np), we need to use eitherrcu_assign_pointer() or WRITE_ONCE() on writer sideto prevent store tearing.I use rcu_assign_pointer() to have lockdep support,this was the choice made in neigh_flush_dev().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()Including the transhdrlen in length is a problem when the packet ispartially filled (e.g. something like send(MSG_MORE) happened previously)when appending to an IPv4 or IPv6 packet as we don't want to repeat thetransport header or account for it twice. This can happen under somecircumstances, such as splicing into an L2TP socket.The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800that occurs when MSG_SPLICE_PAGES is used to append more data to an alreadypartially occupied skbuff. The warning occurs when 'copy' is larger thanthe amount of data in the message iterator. This is because the requestedlength includes the transport header length when it shouldn't. This can betriggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024);Fix this by only adding transhdrlen into the length if the write queue isempty in l2tp_ip6_sendmsg(), analogously to how UDP does things.l2tp_ip_sendmsg() looks like it won't suffer from this problem as it buildsthe UDP packet itself.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reservedAdding a reserved memory region for the framebuffer memory(the splash memory region set up by the bootloader).It fixes a kernel panic (arm-smmu: Unhandled context faultat this particular memory region) reported on DB845c runningv5.10.y.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: Fix possible NULL-pointer dereferenceIn rds_rdma_cm_event_handler_cmn() check, if conn pointer existsbefore dereferencing it as rdma_set_service_type() argumentFound by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/core: Fix ETH_P_1588 flow dissectorWhen a PTP ethernet raw frame with a size of more than 256 bytes followedby a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculationis wrong. For example: hdr->message_length takes the wrong value (0xffff)and it does not replicate real header length. In this case, 'nhoff' valuewas overridden and the PTP header was badly dissected. This leads to akernel crash.net/core: flow_dissectornet/core flow dissector nhoff = 0x0000000enet/core flow dissector hdr->message_length = 0x0000ffffnet/core flow dissector nhoff = 0x0001000d (u16 overflow)...skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffUsing the size of the ptp_header struct will allow the correctedcalculation of the nhoff value.net/core flow dissector nhoff = 0x0000000enet/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)...skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ffskb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffskb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffskb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffKernel trace:[ 74.984279] ------------[ cut here ]------------[ 74.989471] kernel BUG at include/linux/skbuff.h:2440![ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0[ 75.121980] PKRU: 55555554[ 75.125035] Call Trace:[ 75.127792] [ 75.130063] ? eth_get_headlen+0xa4/0xc0[ 75.134472] igc_process_skb_fields+0xcd/0x150[ 75.139461] igc_poll+0xc80/0x17b0[ 75.143272] __napi_poll+0x27/0x170[ 75.147192] net_rx_action+0x234/0x280[ 75.151409] __do_softirq+0xef/0x2f4[ 75.155424] irq_exit_rcu+0xc7/0x110[ 75.159432] common_interrupt+0xb8/0xd0[ 75.163748] [ 75.166112] [ 75.168473] asm_common_interrupt+0x22/0x40[ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350[ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1[ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202[ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f[ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20[ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001[ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980[ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000[ 75.245635] ? ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak when more than 255 elements expiredWhen more than 255 elements expired we're supposed to switch to a new gccontainer structure.This never happens: u8 type will wrap before reaching the boundaryand nft_trans_gc_space() always returns true.This means we recycle the initial gc container structure andlose track of the elements that came before.While at it, don't deref 'gc' after we've passed it to call_rcu.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ptrace: handle setting of fpc register correctlyIf the content of the floating point control (fpc) register of a tracedprocess is modified with the ptrace interface the new value is tested forvalidity by temporarily loading it into the fpc register.This may lead to corruption of the fpc register of the tracing process:if an interrupt happens while the value is temporarily loaded into thefpc register, and within interrupt context floating point or vectorregisters are used, the current fp/vx registers are saved withsave_fpu_regs() assuming they belong to user space and will be loaded intofp/vx registers when returning to user space.test_fp_ctl() restores the original user space fpc register value, howeverit will be discarded, when returning to user space.In result the tracer will incorrectly continue to run with the value thatwas supposed to be used for the traced process.Fix this by saving fpu register contents with save_fpu_regs() before usingtest_fp_ctl().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/lib: Validate size for vector operationsSome of the fp/vmx code in sstep.c assume a certain maximum size for theinstructions being emulated. The size of those operations however isdetermined separately in analyse_instr().Add a check to validate the assumption on the maximum size of theoperations, so as to prevent any unintended kernel stack corruption.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Check mailbox/SMT channel for consistencyOn reception of a completion interrupt the shared memory area is accessedto retrieve the message header at first and then, if the message sequencenumber identifies a transaction which is still pending, the relatedpayload is fetched too.When an SCMI command times out the channel ownership remains with theplatform until eventually a late reply is received and, as a consequence,any further transmission attempt remains pending, waiting for the channelto be relinquished by the platform.Once that late reply is received the channel ownership is given backto the agent and any pending request is then allowed to proceed andoverwrite the SMT area of the just delivered late reply; then the waitfor the reply to the new request starts.It has been observed that the spurious IRQ related to the late reply canbe wrongly associated with the freshly enqueued request: when that happensthe SCMI stack in-flight lookup procedure is fooled by the fact that themessage header now present in the SMT area is related to the new pendingtransaction, even though the real reply has still to arrive.This race-condition on the A2P channel can be detected by looking at thechannel status bits: a genuine reply from the platform will have set thechannel free bit before triggering the completion IRQ.Add a consistency check to validate such condition in the A2P ISR.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ct: fix skb leak and crash on ooo fragsact_ct adds skb->users before defragmentation. If frags arrive in order,the last frag's reference is reset in: inet_frag_reasm_prepare skb_morphwhich is not straightforward.However when frags arrive out of order, nobody unref the last frag, andall frags are leaked. The situation is even worse, as initiating packetcapture can lead to a crash[0] when skb has been cloned and shared at thesame time.Fix the issue by removing skb_get() before defragmentation. act_ctreturns TC_ACT_CONSUMED when defrag failed or in progress.[0]:[ 843.804823] ------------[ cut here ]------------[ 843.809659] kernel BUG at net/core/skbuff.c:2091![ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 843.894229] PKRU: 55555554[ 843.898539] Call Trace:[ 843.902772] [ 843.906922] ? __die_body+0x1e/0x60[ 843.911032] ? die+0x3c/0x60[ 843.915037] ? do_trap+0xe2/0x110[ 843.918911] ? pskb_expand_head+0x2ac/0x300[ 843.922687] ? do_error_trap+0x65/0x80[ 843.926342] ? pskb_expand_head+0x2ac/0x300[ 843.929905] ? exc_invalid_op+0x50/0x60[ 843.933398] ? pskb_expand_head+0x2ac/0x300[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20[ 843.940226] ? pskb_expand_head+0x2ac/0x300[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240[ 843.946904] ip_defrag+0x5d4/0x870[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack][ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct][ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred][ 843.959657] tcf_action_exec+0xa1/0x160[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower][ 843.966010] ? skb_clone+0x53/0xc0[ 843.969173] tcf_classify+0x24d/0x420[ 843.972333] tc_run+0x8f/0xf0[ 843.975465] __netif_receive_skb_core+0x67a/0x1080[ 843.978634] ? dev_gro_receive+0x249/0x730[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core][ 843.991170] napi_complete_done+0x72/0x1a0[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core][ 843.997501] __napi_poll+0x25/0x1b0[ 844.000627] net_rx_action+0x256/0x330[ 844.003705] __do_softirq+0xb3/0x29b[ 844.006718] irq_exit_rcu+0x9e/0xc0[ 844.009672] common_interrupt+0x86/0xa0[ 844.012537] [ 844.015285] [ 844.017937] asm_common_interrupt+0x26/0x40[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix a suspicious RCU usage warningI received the following warning while running cthon against an ontapserver running pNFS:[ 57.202521] =============================[ 57.202522] WARNING: suspicious RCU usage[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted[ 57.202525] -----------------------------[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!![ 57.202527] other info that might help us debug this:[ 57.202528] rcu_scheduler_active = 2, debug_locks = 1[ 57.202529] no locks held by test5/3567.[ 57.202530] stack backtrace:[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022[ 57.202536] Call Trace:[ 57.202537] [ 57.202540] dump_stack_lvl+0x77/0xb0[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202866] write_cache_pages+0x265/0x450[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202913] do_writepages+0xd2/0x230[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80[ 57.202924] filemap_write_and_wait_range+0xd9/0x170[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202969] __se_sys_close+0x46/0xd0[ 57.202972] do_syscall_64+0x68/0x100[ 57.202975] ? do_syscall_64+0x77/0x100[ 57.202976] ? do_syscall_64+0x77/0x100[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76[ 57.202982] RIP: 0033:0x7fe2b12e4a94[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49[ 57.202993] R10: 00007f---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7091r: Allow users to configure device eventsAD7091R-5 devices are supported by the ad7091r-5 driver together withthe ad7091r-base driver. Those drivers declared iio events for notifyinguser space when ADC readings fall bellow the thresholds of low limitregisters or above the values set in high limit registers.However, to configure iio events and their thresholds, a set of callbackfunctions must be implemented and those were not present until now.The consequence of trying to configure ad7091r-5 events without theproper callback functions was a null pointer dereference in the kernelbecause the pointers to the callback functions were not set.Implement event configuration callbacks allowing users to read/writeevent thresholds and enable/disable event generation.Since the event spec structs are generic to AD7091R devices, also movethose from the ad7091r-5 driver the base driver so they can be reusedwhen support for ad7091r-2/-4/-8 be added.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix lock dependency warning with srcu======================================================WARNING: possible circular locking dependency detected6.5.0-kfd-yangp #2289 Not tainted------------------------------------------------------kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0-> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80-> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0other info that might help us debug this:Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: prevent deadlock by changing j1939_socks_lock to rwlockThe following 3 locks would race against each other, causing thedeadlock situation in the Syzbot bug report:- j1939_socks_lock- active_session_list_lock- sk_session_queue_lockA reasonable fix is to change j1939_socks_lock to an rwlock, since inthe rare situations where a write lock is required for the linked listthat j1939_socks_lock is protecting, the code does not attempt toacquire any more locks. This would break the circular lock dependency,where, for example, the current thread already locks j1939_socks_lockand attempts to acquire sk_session_queue_lock, and at the same time,another thread attempts to acquire j1939_socks_lock while holdingsk_session_queue_lock.NOTE: This patch along does not fix the unregister_netdevice bugreported by Syzbot; instead, it solves a deadlock situation to preparefor one or more further patches to actually fix the Syzbot bug, whichappears to be a reference counting problem within the j1939 codebase.[mkl: remove unrelated newline change]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: bpf attach/detach requires write permissionNote that bpf attach/detach also requires CAP_NET_ADMIN.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabledWhen QoS is disabled, the queue priority value will not map to the correctieee80211 queue since there is only one queue. Stop/wake queue 0 when QoSis disabled to prevent trying to stop/wake a non-existent queue and failingto stop/wake the actual queue instantiated.Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: mediatek: fix race conditions with genpdIf the power domains are registered first with genpd and *after that*the driver attempts to power them on in the probe sequence, then it ispossible that a race condition occurs if genpd tries to power them onin the same time.The same is valid for powering them off before unregistering themfrom genpd.Attempt to fix race conditions by first removing the domains from genpdand *after that* powering down domains.Also first power up the domains and *after that* register themto genpd.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:aio: fix mremap after fork null-derefCommit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduceda null-deref if mremap is called on an old aio mapping after fork asmm->ioctx_table will be set to NULL.[jmoyer@redhat.com: fix 80 column issue]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: eliminate double free in error handling logicDriver has a logic leak in ring data allocation/free,where aq_ring_free could be called multiple times on same ring,if system is under stress and got memory allocation error.Ring pointer was used as an indicator of failure, but this isnot correct since only ring data is allocated/deallocated.Ring itself is an array member.Changing ring allocation functions to return error code directly.This simplifies error handling and eliminates aq_ring_freeon higher layer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: s390/aes - Fix buffer overread in CTR modeWhen processing the last block, the s390 ctr code will always reada whole block, even if there isn't a whole block of data left. Fixthis by using the actual length left and copy it into a buffer firstfor processing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:pipe: wakeup wr_wait after setting max_usageCommit c73be61cede5 ("pipe: Add general notification queue support") aregression was introduced that would lock up resized pipes under certainconditions. See the reproducer in [1].The commit resizing the pipe ring size was moved to a differentfunction, doing that moved the wakeup for pipe->wr_wait before actuallyraising pipe->max_usage. If a pipe was full before the resize occured itwould result in the wakeup never actually triggering pipe_write.Set @max_usage and @nr_accounted before waking writers if this isn't awatch queue.[Christian Brauner : rewrite to account for watch queues]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 andSCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outsidescarlett2_mixer_values[].

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:of: Fix double free in of_parse_phandle_with_args_mapIn of_parse_phandle_with_args_map() the inner loop thatiterates through the map entries calls of_node_put(new)to free the reference acquired by the previous iterationof the inner loop. This assumes that the value of "new" isNULL on the first iteration of the inner loop.Make sure that this is true in all iterations of the outerloop by setting "new" to NULL after its value is assigned to "cur".Extend the unittest to detect the double free and add an additionaltest case that actually triggers this path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add missing error checks to *_ctl_get()The *_ctl_get() functions which call scarlett2_update_*() were notchecking the return value. Fix to check the return value and pass tothe caller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: LPIT: Avoid u32 multiplication overflowIn lpit_update_residency() there is a possibility of overflowin multiplication, if tsc_khz is large enough (> UINT_MAX/1000).Change multiplication to mul_u32_u32().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix a double-free in si_dpm_initWhen the allocation ofadev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,amdgpu_free_extended_power_table is called to free some fields of adev.However, when the control flow returns to si_dpm_sw_init, it goes tolabel dpm_failed and calls si_dpm_fini, which callsamdgpu_free_extended_power_table again and free those fields again. Thusa double-free is triggered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()scarlett2_usb_set_config() calls scarlett2_usb_get() but was notchecking the result. Return the error if it fails rather thancontinuing with an invalid value.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: check for error while searching for backlight device parentIf acpi_get_parent() called in acpi_video_dev_register_backlight()fails, for example, because acpi_ut_acquire_mutex() fails insideacpi_get_parent), this can lead to incorrect (uninitialized)acpi_parent handle being passed to acpi_get_pci_dev() for detectingthe parent pci device.Check acpi_get_parent() result and set parent device only in case of success.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: tpd12s015: Drop buggy __exit annotation for remove functionWith tpd12s015_remove() marked with __exit this function is discardedwhen the driver is compiled as a built-in. The result is that when thedriver unbinds there is no cleanup done which results in resourceleakage or worse.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix underflow in second superblock position calculationsMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the secondsuperblock, underflows when the argument device size is less than 4096bytes. Therefore, when using this macro, it is necessary to check inadvance that the device size is not less than a lower limit, or at leastthat underflow does not occur.The current nilfs2 implementation lacks this check, causing out-of-boundblock access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)In addition, when trying to resize the filesystem to a size below 4096bytes, this underflow occurs in nilfs_resize_fs(), passing a huge numberof segments to nilfs_sufile_resize(), corrupting parameters such as thenumber of segments in superblocks. This causes excessive loop iterationsin nilfs_sufile_resize() during a subsequent resize ioctl, causingsemaphore ns_segctor_sem to block for a long time and hang the writerthread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 ... Call Trace: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...This fixes these issues by inserting appropriate minimum device sizechecks or anti-underflow checks, depending on where the macro is used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itselfsock_map proto callbacks should never call themselves by design. Protectagainst bugs like [1] and break out of the recursive loop to avoid a stackoverflow in favor of a resource leak.[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newerPrior to LLVM 15.0.0, LLVM's integrated assembler would incorrectlybyte-swap NOP when compiling for big-endian, and the resulting series ofbytes happened to match the encoding of FNMADD S21, S30, S0, S0.This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")Prior to that commit, the kernel would always enable the use of FPSIMDearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage ofFNMADD within the kernel was not detected, but could result in thecorruption of user or kernel FPSIMD state.After that commit, the instructions happen to trap during boot prior toFPSIMD being detected and enabled, e.g.| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : __pi_strcmp+0x1c/0x150| lr : populate_properties+0xe4/0x254| sp : ffffd014173d3ad0| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8| Kernel panic - not syncing: Unhandled exception| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| Call trace:| dump_backtrace+0xec/0x108| show_stack+0x18/0x2c| dump_stack_lvl+0x50/0x68| dump_stack+0x18/0x24| panic+0x13c/0x340| el1t_64_irq_handler+0x0/0x1c| el1_abort+0x0/0x5c| el1h_64_sync+0x64/0x68| __pi_strcmp+0x1c/0x150| unflatten_dt_nodes+0x1e8/0x2d8| __unflatten_device_tree+0x5c/0x15c| unflatten_device_tree+0x38/0x50| setup_arch+0x164/0x1e0| start_kernel+0x64/0x38c| __primary_switched+0xbc/0xc4Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which iseither GNU as or LLVM's IAS 15.0.0 and newer, which contains the linkedcommit.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in smb2_query_info_compound()The following UAF was triggered when running fstests generic/072 withKASAN enabled against Windows Server 2022 and mount options'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs]This is a race between open_cached_dir() and cached_dir_lease_break()where the cache entry for the open directory handle receives a leasebreak while creating it. And before returning from open_cached_dir(),we put the last reference of the new @cfid because of!@cfid->has_lease.Besides the UAF, while running xfstests a lot of missed lease breakshave been noticed in tests that run several concurrent statfs(2) callson those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ...To fix both, in open_cached_dir() ensure that @cfid->has_lease is setright before sending out compounded request so that any potentiallease break will be get processed by demultiplex thread while we'restill caching @cfid. And, if open failed for some reason, re-check@cfid->has_lease to decide whether or not put lease reference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: add ipvlan_route_v6_outbound() helperInspired by syzbot reports using a stack of multiple ipvlan devices.Reduce stack size needed in ipvlan_process_v6_outbound() by movingthe flowi6 struct used for the route lookup in an non inlinedhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,immediately reclaimed.Also make sure ipvlan_process_v4_outbound() is not inlined.We might also have to lower MAX_NEST_DEV, because only syzbot usessetups with more than four stacked devices.BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)stack guard page: 0000 [#1] SMP KASANCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89RSP: 0018:ffffc9000e804000 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080cR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:<#DF>[] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31[] instrument_atomic_read include/linux/instrumented.h:72 [inline][] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline][] cpumask_test_cpu include/linux/cpumask.h:506 [inline][] cpu_online include/linux/cpumask.h:1092 [inline][] trace_lock_acquire include/trace/events/lock.h:24 [inline][] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632[] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306[] rcu_read_lock include/linux/rcupdate.h:747 [inline][] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221[] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606[] pol_lookup_func include/net/ip6_fib.h:584 [inline][] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116[] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638[] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651[] ip6_route_output include/net/ip6_route.h:100 [inline][] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4966 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324[] dev_queue_xmit include/linux/netdevice.h:3067 [inline][] neigh_hh_output include/net/neighbour.h:529 [inline][

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfsIf init debugfs failed during device registration due to memory allocationfailure, debugfs_remove_recursive() is called, after which debugfs_dir isnot set to NULL. debugfs_remove_recursive() will be called again duringdevice removal. As a result, illegal pointer is accessed.[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!...[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 1669.872669] pc : down_write+0x24/0x70[ 1669.876315] lr : down_write+0x1c/0x70[ 1669.879961] sp : ffff000036f53a30[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001[ 1669.962563] Call trace:[ 1669.965000] down_write+0x24/0x70[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main][ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw][ 1669.984175] pci_device_remove+0x48/0xd8[ 1669.988082] device_release_driver_internal+0x1b4/0x250[ 1669.993282] device_release_driver+0x28/0x38[ 1669.997534] pci_stop_bus_device+0x84/0xb8[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40[ 1670.007244] remove_store+0xfc/0x140[ 1670.010802] dev_attr_store+0x44/0x60[ 1670.014448] sysfs_kf_write+0x58/0x80[ 1670.018095] kernfs_fop_write+0xe8/0x1f0[ 1670.022000] __vfs_write+0x60/0x190[ 1670.025472] vfs_write+0xac/0x1c0[ 1670.028771] ksys_write+0x6c/0xd8[ 1670.032071] __arm64_sys_write+0x24/0x30[ 1670.035977] el0_svc_common+0x78/0x130[ 1670.039710] el0_svc_handler+0x38/0x78[ 1670.043442] el0_svc+0x8/0xcTo fix this, set debugfs_dir to NULL after debugfs_remove_recursive().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst->flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon't call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&wait->completion), which will causehungtask.The problem comes as following:(padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:llc: verify mac len before reading mac headerLLC reads the mac header with eth_hdr without verifying that the skbhas an Ethernet header.Syzbot was able to enter llc_rcv on a tun device. Tun can insertpackets without mac len and with user configurable skb->protocol(passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002Add a mac_len test before all three eth_hdr(skb) calls under net/llc.There are further uses in include/net/llc_pdu.h. All these areprotected by a test skb->protocol == ETH_P_802_2. Which does notprotect against this tun scenario.But the mac_len test added in this patch in llc_fixup_skb willindirectly protect those too. That is called from llc_rcv before anyother LLC code.It is tempting to just add a blanket mac_len check in llc_rcv, butnot sure whether that could break valid LLC paths that do not assumean Ethernet header. 802.2 LLC may be used on top of non-802.3protocols in principle. The below referenced commit shows that usedto, on top of Token Ring.At least one of the three eth_hdr uses goes back to before the startof git history. But the one that syzbot exercises is introduced inthis commit. That commit is old enough (2008), that effectively allstable kernels should receive this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Change nla_policy for bearer-related names to NLA_NUL_STRINGsyzbot reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdTIPC bearer-related names including link names must be null-terminatedstrings. If a link name which is not null-terminated is passed throughnetlink, strstr() and similar functions can cause buffer overrun. Thiscauses the above issue.This patch changes the nla_policy for bearer-related names from NLA_STRINGto NLA_NUL_STRING. This resolves the issue by ensuring that onlynull-terminated strings are accepted as bearer-related names.syzbot reported similar uninit-value issue related to bearer names [2]. Theroot cause of this issue is that a non-null-terminated bearer name waspassed. This patch also resolved this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (axi-fan-control) Fix possible NULL pointer dereferenceaxi_fan_control_irq_handler(), dependent on the privateaxi_fan_control_data structure, might be called before the hwmondevice is registered. That will cause an "Unable to handle kernelNULL pointer dereference" error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: Fix null pointer deref when receiving skb during sock creationThe panic below is observed when receiving ICMP packets with secmark setwhile an ICMP raw socket is being created. SK_CTX(sk)->label is updatedin apparmor_socket_post_create(), but the packet is delivered to thesocket before that, causing the null pointer dereference.Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? aa_label_next_confined+0xb/0x40 apparmor_secmark_check+0xec/0x330 security_sock_rcv_skb+0x35/0x50 sk_filter_trim_cap+0x47/0x250 sock_queue_rcv_skb_reason+0x20/0x60 raw_rcv+0x13c/0x210 raw_local_deliver+0x1f3/0x250 ip_protocol_deliver_rcu+0x4f/0x2f0 ip_local_deliver_finish+0x76/0xa0 __netif_receive_skb_one_core+0x89/0xa0 netif_receive_skb+0x119/0x170 ? __netdev_alloc_skb+0x3d/0x140 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] __napi_poll+0x28/0x1b0 net_rx_action+0x2a4/0x380 __do_softirq+0xd1/0x2c8 __irq_exit_rcu+0xbb/0xf0 common_interrupt+0x86/0xa0 asm_common_interrupt+0x26/0x40 RIP: 0010:apparmor_socket_post_create+0xb/0x200 Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48 RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286 RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003 R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748 ? __pfx_apparmor_socket_post_create+0x10/0x10 security_socket_post_create+0x4b/0x80 __sock_create+0x176/0x1f0 __sys_socket+0x89/0x100 __x64_sys_socket+0x17/0x20 do_syscall_64+0x5d/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Add exception protection processing for vd in axi_chan_handle_err functionSince there is no protection for vd, a kernel panic will betriggered here in exceptional cases.You can refer to the processing of axi_chan_block_xfer_complete functionThe triggered kernel panic is as follows:[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 67.848447] Mem abort info:[ 67.848449] ESR = 0x96000004[ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits[ 67.848454] SET = 0, FnV = 0[ 67.848456] EA = 0, S1PTW = 0[ 67.848458] Data abort info:[ 67.848460] ISV = 0, ISS = 0x00000004[ 67.848462] CM = 0, WnR = 0[ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000[ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000[ 67.848472] Internal error: Oops: 96000004 [#1] SMP[ 67.848475] Modules linked in: dmatest[ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11[ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)[ 67.848487] pc : axi_chan_handle_err+0xc4/0x230[ 67.848491] lr : axi_chan_handle_err+0x30/0x230[ 67.848493] sp : ffff0803fe55ae50[ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200[ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080[ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850[ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000[ 67.848512] x21: 0000000000000080 x20: 0000000000002000[ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000[ 67.848521] x17: 0000000000000000 x16: 0000000000000000[ 67.848525] x15: 0000000000000000 x14: 0000000000000000[ 67.848529] x13: 0000000000000000 x12: 0000000000000040[ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a[ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270[ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0[ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480[ 67.848550] x3 : dead000000000100 x2 : dead000000000122[ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168[ 67.848559] Call trace:[ 67.848562] axi_chan_handle_err+0xc4/0x230[ 67.848566] dw_axi_dma_interrupt+0xf4/0x590[ 67.848569] __handle_irq_event_percpu+0x60/0x220[ 67.848573] handle_irq_event+0x64/0x120[ 67.848576] handle_fasteoi_irq+0xc4/0x220[ 67.848580] __handle_domain_irq+0x80/0xe0[ 67.848583] gic_handle_irq+0xc0/0x138[ 67.848585] el1_irq+0xc8/0x180[ 67.848588] arch_cpu_idle+0x14/0x2c[ 67.848591] default_idle_call+0x40/0x16c[ 67.848594] do_idle+0x1f0/0x250[ 67.848597] cpu_startup_entry+0x2c/0x60[ 67.848600] rest_init+0xc0/0xcc[ 67.848603] arch_call_rest_init+0x14/0x1c[ 67.848606] start_kernel+0x4cc/0x500[ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)[ 67.848613] ---[ end trace 585a97036f88203a ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mpls: Fix warning during failed attribute validationThe 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has avalidation type of 'NLA_VALIDATE_FUNCTION'. This is an invalidcombination according to the comment above 'struct nla_policy':"Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union"This can trigger the warning [1] in nla_get_range_unsigned() whenvalidation of the attribute fails. Despite being of 'NLA_U32' type, theassociated 'min'/'max' fields in the policy are negative as they arealiased by the 'validate' field.Fix by changing the attribute type to 'NLA_BINARY' which is consistentwith the above comment and all other users of NLA_POLICY_VALIDATE_FN().As a result, move the length validation to the validation function.No regressions in MPLS tests: # ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0[1]WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117Modules linked in:CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117[...]Call Trace: __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xferIn af9035_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9035_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: aspeed: Fix memory overwrite if timing is 1600x900When capturing 1600x900, system could crash when system memory usage istight.The way to reproduce this issue:1. Use 1600x900 to display on host2. Mount ISO through 'Virtual media' on OpenBMC's web3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done4. Open KVM on OpenBMC's webThe size of macro block captured is 8x8. Therefore, we should make surethe height of src-buf is 8 aligned to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: check cx23885_vdev_init() returncx23885_vdev_init() can return a NULL pointer, but that pointeris used in the next line without a check.Add a NULL pointer check and go to the error unwind if it is NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: support non-r10 register spill/fill to/from stack in precision trackingUse instruction (jump) history to record instructions that performedregister spill/fill to/from stack, regardless if this was done throughread-only r10 register, or any other register after copying r10 into it*and* potentially adjusting offset.To make this work reliably, we push extra per-instruction flags intoinstruction history, encoding stack slot index (spi) and stack framenumber in extra 10 bit flags we take away from prev_idx in instructionhistory. We don't touch idx field for maximum performance, as it'schecked most frequently during backtracking.This change removes basically the last remaining practical limitation ofprecision backtracking logic in BPF verifier. It fixes knowndeficiencies, but also opens up new opportunities to reduce number ofverified states, explored in the subsequent patches.There are only three differences in selftests' BPF object filesaccording to veristat, all in the positive direction (less states).File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)Note, I avoided renaming jmp_history to more generic insn_hist tominimize number of lines changed and potential merge conflicts betweenbpf and bpf-next trees.Notice also cur_hist_entry pointer reset to NULL at the beginning ofinstruction verification loop. This pointer avoids the problem ofrelying on last jump history entry's insn_idx to determine whether wealready have entry for current instruction or not. It can happen that weadded jump history entry because current instruction is_jmp_point(), butalso we need to add instruction flags for stack access. In this case, wedon't want to entries, so we need to reuse last added entry, if it ispresent.Relying on insn_idx comparison has the same ambiguity problem as the onethat was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: kprobe: Fixup kernel panic when probing an illegal positionThe kernel would panic when probed for an illegal position. eg:(CONFIG_RISCV_ISA_C=n)echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_eventsecho 1 > events/kprobes/hello/enablecat traceKernel panic - not syncing: stack-protector: Kernel stackis corrupted in: __do_sys_newfstatat+0xb8/0xb8CPU: 0 PID: 111 Comm: sh Not tainted6.2.0-rc1-00027-g2d398fe49a4d #490Hardware name: riscv-virtio,qemu (DT)Call Trace:[] dump_backtrace+0x38/0x48[] show_stack+0x50/0x68[] dump_stack_lvl+0x60/0x84[] dump_stack+0x20/0x30[] panic+0x160/0x374[] generic_handle_arch_irq+0x0/0xa8[] sys_newstat+0x0/0x30[] sys_clone+0x20/0x30[] ret_from_syscall+0x0/0x4---[ end Kernel panic - not syncing: stack-protector:Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]---That is because the kprobe's ebreak instruction broke the kernel'soriginal code. The user should guarantee the correction of the probeposition, but it couldn't make the kernel panic.This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent anillegal position (Such as the middle of an instruction).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix request ref counting during error capture & debugfs dumpWhen GuC support was added to error capture, the reference countingaround the request object was broken. Fix it up.The context based search manages the spinlocking around the searchinternally. So it needs to grab the reference count internally aswell. The execlist only request based search relies on externallocking, so it needs an external reference count but within thespinlock not outside it.The only other caller of the context based search is the code fordumping engine state to debugfs. That code wasn't previously gettingan explicit reference at all as it does everything while holding theexeclist specific spinlock. So, that needs updaing as well as thatspinlock doesn't help when using GuC submission. Rather than trying toconditionally get/put depending on submission model, just change it toalways do the get/put.v2: Explicitly document adding an extra blank line in some dense code(Andy Shevchenko). Fix multiple potential null pointer derefs in caseof no request found (some spotted by Tvrtko, but there was more!).Also fix a leaked request in case of !started and another in__guc_reset_context now that intel_context_find_active_request isactually reference counting the returned request.v3: Add a _get suffix to intel_context_find_active_request now that itgrabs a reference (Daniele).v4: Split the intel_guc_find_hung_context change to a separate patchand rename intel_context_find_active_request_get tointel_context_get_active_request (Tvrtko).v5: s/locking/reference counting/ in commit message (Tvrtko)(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listenerA listening socket linked to a sockmap has its sk_prot overridden. Itpoints to one of the struct proto variants in tcp_bpf_prots. The variantdepends on the socket's family and which sockmap programs are attached.A child socket cloned from a TCP listener initially inherits their sk_prot.But before cloning is finished, we restore the child's proto to thelistener's original non-tcp_bpf_prots one. This happens intcp_create_openreq_child -> tcp_bpf_clone.Today, in tcp_bpf_clone we detect if the child's proto should be restoredby checking only for the TCP_BPF_BASE proto variant. This is notcorrect. The sk_prot of listening socket linked to a sockmap can point toto any variant in tcp_bpf_prots.If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, thenthe child socket unintentionally is left if the inherited sk_prot bytcp_bpf_clone.This leads to issues like infinite recursion on close [1], because thechild state is otherwise not set up for use with tcp_bpf_prot operations.Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.Note that it wouldn't be sufficient to check the socket state whenoverriding the sk_prot in tcp_bpf_update_proto in order to always use theTCP_BPF_BASE variant for listening sockets. Since commitb8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")it is possible for a socket to transition to TCP_LISTEN state while alreadylinked to a sockmap, e.g. connect() -> insert into map ->connect(AF_UNSPEC) -> listen().[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer in skb_segment_listCommit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")introduced UDP listifyed GRO. The segmentation relies on frag_list beinguntouched when passing through the network stack. This assumption can bebroken sometimes, where frag_list itself gets pulled into linear area,leaving frag_list being NULL. When this happens it can triggerfollowing NULL pointer dereference, and panic the kernel. Reverse thetest condition should fix it.[19185.577801][ C1] BUG: kernel NULL pointer dereference, address:...[19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390...[19185.834644][ C1] Call Trace:[19185.841730][ C1] [19185.848563][ C1] __udp_gso_segment+0x33e/0x510[19185.857370][ C1] inet_gso_segment+0x15b/0x3e0[19185.866059][ C1] skb_mac_gso_segment+0x97/0x110[19185.874939][ C1] __skb_gso_segment+0xb2/0x160[19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0[19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90[19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200[19185.910003][ C1] ip_local_deliver_finish+0x44/0x60[19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0[19185.927834][ C1] process_backlog+0x88/0x130[19185.935840][ C1] __napi_poll+0x27/0x150[19185.943447][ C1] net_rx_action+0x27e/0x5f0[19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core][19185.960848][ C1] __do_softirq+0xbc/0x25d[19185.968607][ C1] irq_exit_rcu+0x83/0xb0[19185.976247][ C1] common_interrupt+0x43/0xa0[19185.984235][ C1] asm_common_interrupt+0x22/0x40...[19186.094106][ C1]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: Fix suspend with Xen PVCommit f1e525009493 ("x86/boot: Skip realmode init code when running asXen PV guest") missed one code path accessing real_mode_header, leadingto dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20Fix that by adding an optional acpi callback allowing to skip settingthe wakeup address, as in the Xen PV case this will be handled by thehypervisor anyway.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:riscv/kprobe: Fix instruction simulation of JALRSet kprobe at 'jalr 1140(ra)' of vfs_write results in the followingcrash:[ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170[ 32.093115] Oops [#1][ 32.093251] Modules linked in:[ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16[ 32.093985] Hardware name: riscv-virtio,qemu (DT)[ 32.094280] epc : ksys_read+0x88/0xd6[ 32.094855] ra : ksys_read+0xc0/0xd6[ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0[ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80[ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60[ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708[ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300[ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff[ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170[ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030[ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410[ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c[ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54[ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d[ 32.098011] [] ksys_write+0x6c/0xd6[ 32.098222] [] sys_write+0x2a/0x38[ 32.098405] [] ret_from_syscall+0x0/0x2Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)',hence it requires obtaining the target address from rs1 followed byupdating rd.[Palmer: Pick Guo's cleanup]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in fib_metrics_match()if (!type) continue; if (type > RTAX_MAX) return false; ... fi_val = fi->fib_metrics->metrics[type - 1];@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val;@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix a memory leak with reused mmap_offsetdrm_vma_node_allow() and drm_vma_node_revoke() should be called inbalanced pairs. We call drm_vma_node_allow() once per-file everytime auser calls mmap_offset, but only call drm_vma_node_revoke once per-fileon each mmap_offset. As the mmap_offset is reused by the client, theper-file vm_count may remain non-zero and the rbtree leaked.Call drm_vma_node_allow_once() instead to prevent that memory leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_infoThe memory for llcc_driv_data is allocated by the LLCC driver. But whenit is passed as the private driver info to the EDAC core, it will get freedduring the qcom_edac driver release. So when the qcom_edac driver gets probedagain, it will try to use the freed data leading to the use-after-free bug.Hence, do not pass llcc_driv_data as pvt_info but rather reference itusing the platform_data pointer in the qcom_edac driver.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add sync after creating vram boThere will be data corruption on vram allocated by svmif the initialization is not complete and application iswritting on the memory. Adding sync to wait for theinitialization completion is to resolve this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: enable all safety features by defaultIn the original implementation of dwmac5commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")all safety features were enabled by default.Later it seems some implementations didn't have support for all thefeatures, so incommit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")the safety_feat_cfg structure was added to the callback and defined forsome platforms to selectively enable these safety features.The problem is that only certain platforms were given that softwaresupport. If the automotive safety package bit is set in the hardwarefeatures register the safety feature callback is called for the platform,and for platforms that didn't get a safety_feat_cfg defined this resultsin the following NULL pointer dereference:[ 7.933303] Call trace:[ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac][ 7.941455] __stmmac_open+0x16c/0x474 [stmmac][ 7.946117] stmmac_open+0x38/0x70 [stmmac][ 7.950414] __dev_open+0x100/0x1dc[ 7.954006] __dev_change_flags+0x18c/0x204[ 7.958297] dev_change_flags+0x24/0x6c[ 7.962237] do_setlink+0x2b8/0xfa4[ 7.965827] __rtnl_newlink+0x4ec/0x840[ 7.969766] rtnl_newlink+0x50/0x80[ 7.973353] rtnetlink_rcv_msg+0x12c/0x374[ 7.977557] netlink_rcv_skb+0x5c/0x130[ 7.981500] rtnetlink_rcv+0x18/0x2c[ 7.985172] netlink_unicast+0x2e8/0x340[ 7.989197] netlink_sendmsg+0x1a8/0x420[ 7.993222] ____sys_sendmsg+0x218/0x280[ 7.997249] ___sys_sendmsg+0xac/0x100[ 8.001103] __sys_sendmsg+0x84/0xe0[ 8.004776] __arm64_sys_sendmsg+0x24/0x30[ 8.008983] invoke_syscall+0x48/0x114[ 8.012840] el0_svc_common.constprop.0+0xcc/0xec[ 8.017665] do_el0_svc+0x38/0xb0[ 8.021071] el0_svc+0x2c/0x84[ 8.024212] el0t_64_sync_handler+0xf4/0x120[ 8.028598] el0t_64_sync+0x190/0x194Go back to the original behavior, if the automotive safety packageis found to be supported in hardware enable all the features unlesssafety_feat_cfg is passed in saying this particular platform onlysupports a subset of the features.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: call put_device() only after device_register() failsput_device() shouldn't be called before a prior call todevice_register(). __thermal_cooling_device_register() doesn't followthat properly and needs fixing. Alsothermal_cooling_device_destroy_sysfs() is getting called unnecessarilyon few error paths.Fix all this by placing the calls at the right place.Based on initial work done by Caleb Connolly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ptdma: pt_core_execute_cmd() should use spinlockThe interrupt handler (pt_core_irq_handler()) of the ptdmadriver can be called from interrupt context. The code flowin this function can lead down to pt_core_execute_cmd() whichwill attempt to grab a mutex, which is not appropriate ininterrupt context and ultimately leads to a kernel panic.The fix here changes this mutex to a spinlock, which hasbeen verified to resolve the issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: close all race conditions in l2tp_tunnel_register()The code in l2tp_tunnel_register() is racy in several ways:1. It modifies the tunnel socket _after_ publishing it.2. It calls setup_udp_tunnel_sock() on an existing socket without locking.3. It changes sock lock class on fly, which triggers many syzbot reports.This patch amends all of them by moving socket initialization codebefore publishing and under sock lock. As suggested by Jakub, thel2tp lockdep class is not necessary as we can just switch tobh_lock_sock_nested().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_taprio: fix possible use-after-freesyzbot reported a nasty crash [1] in net_tx_action() whichmade little sense until we got a repro.This repro installs a taprio qdisc, but providing aninvalid TCA_RATE attribute.qdisc_create() has to destroy the just initializedtaprio qdisc, and taprio_destroy() is called.However, the hrtimer used by taprio had already fired,therefore advance_sched() called __netif_schedule().Then net_tx_action was trying to use a destroyed qdisc.We can not undo the __netif_schedule(), so we must waituntil one cpu serviced the qdisc before we can proceed.Many thanks to Alexander Potapenko for his help.[1]BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] do_raw_spin_trylock include/linux/spinlock.h:191 [inline] __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock include/linux/spinlock.h:359 [inline] qdisc_run_begin include/net/sch_generic.h:187 [inline] qdisc_run+0xee/0x540 include/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30Uninit was created at: slab_post_alloc_hook mm/slab.h:732 [inline] slab_alloc_node mm/slub.c:3258 [inline] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [inline] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [inline] __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdCPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()This lockdep splat says it better than I could:================================WARNING: inconsistent lock state6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted--------------------------------inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0{IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64irq event stamp: 7825hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); lock(_xmit_ETHER#2); *** DEADLOCK ***3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34Workqueue: events enetc_tx_onestep_tstampCall trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11cbut I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs inprocess context, therefore with softirqs enabled (i.o.w., it can beinterrupted by a softirq). If we hold the netif_tx_lock() when there isan interrupt, and the NET_TX softirq then gets scheduled, this will takethe netif_tx_lock() a second time and deadlock the kernel.To solve this, use netif_tx_lock_bh(), which blocks softirqs fromrunning.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/imc-pmu: Fix use of mutex in IRQs disabled sectionCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEPand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sysBelow is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1The above warning triggered because the current imc-pmu code uses mutexlock in interrupt disabled sections. The function mutex_lock()internally calls __might_resched(), which will check if IRQs aredisabled and in case IRQs are disabled, it will trigger the warning.Fix the issue by changing the mutex lock to spinlock.[mpe: Fix comments, trim oops in change log, add reported-by tags]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value ofan arithmetic expression 2 << (netmask - mask_bits - 1) is subjectto overflow due to a failure casting operands to a larger data typebefore performing the arithmetic.Note that it's harmless since the value will be checked at the next step.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix race condition in amdtee_open_sessionThere is a potential race condition in amdtee_open_session that maylead to use-after-free. For instance, in amdtee_open_session() aftersess->sess_mask is set, and before setting: sess->session_info[i] = session_info;if amdtee_close_session() closes this same session, then 'sess' datastructure will be released, causing kernel panic when 'sess' isaccessed within amdtee_open_session().The solution is to set the bit sess->sess_mask as the last step inamdtee_open_session().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: do not use skb_mac_header() in ndo_start_xmit()Drivers should not assume skb_mac_header(skb) == skb->data in theirndo_start_xmit().Use skb_network_offset() and skb_transport_offset() whichbetter describe what is needed in erspan_fb_xmit() andip6erspan_tunnel_xmit()syzbot reported:WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962Modules linked in:CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__netdev_start_xmit include/linux/netdevice.h:4900 [inline]netdev_start_xmit include/linux/netdevice.h:4914 [inline]__dev_direct_xmit+0x504/0x730 net/core/dev.c:4300dev_direct_xmit include/linux/netdevice.h:3088 [inline]packet_xmit+0x20a/0x390 net/packet/af_packet.c:285packet_snd net/packet/af_packet.c:3075 [inline]packet_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg+0xde/0x190 net/socket.c:747__sys_sendto+0x23a/0x340 net/socket.c:2142__do_sys_sendto net/socket.c:2154 [inline]__se_sys_sendto net/socket.c:2150 [inline]__x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f123aaa1039Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-vf: Add missing free for alloc_percpuAdd the free_percpu for the allocated "vf->hw.lmt_info" in order to avoidmemory leak, same as the "pf->hw.lmt_info" in`drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: use the workqueue to destroy unaccepted socketsChristoph reported a UaF at token lookup time after havingrefactored the passive socket initialization part: BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcWe need to properly clean-up all the paired MPTCP-levelresources and be sure to release the msk last, even whenthe unaccepted subflow is destroyed by the TCP internalsvia inet_child_forget().We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,explicitly checking that for the critical scenario: theclosed subflow is the MPC one, the msk is not accepted andeventually going through full cleanup.With such change, __mptcp_destroy_sock() is always calledon msk sockets, even on accepted ones. We don't need anymoreto transiently drop one sk reference at msk clone time.Please note this commit depends on the parent one: mptcp: refactor passive socket initialization

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Add missing overflow check in xdp_umem_regThe number of chunks can overflow u32. Make sure to return -EINVAL onoverflow. Also remove a redundant u32 cast assigning umem->npgs.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: fsl_lpuart: fix race on RX DMA shutdownFrom time to time DMA completion can come in the middle of DMA shutdown:: :lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free()When the timer fires a bit later, sport->dma_rx_desc is NULL:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004pc : lpuart_copy_rx_to_tty+0xcc/0x5bclr : lpuart_timer_func+0x1c/0x2cCall trace: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ...To fix this fold del_timer_sync() into lpuart_dma_rx_free() afterdmaengine_terminate_sync() to make sure timer will not be re-started inlpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ice: xsk: disable txq irq before flushing hwice_qp_dis() intends to stop a given queue pair that is a target of xskpool attach/detach. One of the steps is to disable interrupts on thesequeues. It currently is broken in a way that txq irq is turned off*after* HW flush which in turn takes no effect.ice_qp_dis():-> ice_qvec_dis_irq()--> disable rxq irq--> flush hw-> ice_vsi_stop_tx_ring()-->disable txq irqBelow splat can be triggered by following steps:- start xdpsock WITHOUT loading xdp prog- run xdp_rxq_info with XDP_TX action on this interface- start traffic- terminate xdpsock[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018[ 256.319560] #PF: supervisor read access in kernel mode[ 256.324775] #PF: error_code(0x0000) - not-present page[ 256.329994] PGD 0 P4D 0[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice][ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 256.457770] PKRU: 55555554[ 256.460529] Call Trace:[ 256.463015] [ 256.465157] ? ice_xmit_zc+0x6e/0x150 [ice][ 256.469437] ice_napi_poll+0x46d/0x680 [ice][ 256.473815] ? _raw_spin_unlock_irqrestore+0x1b/0x40[ 256.478863] __napi_poll+0x29/0x160[ 256.482409] net_rx_action+0x136/0x260[ 256.486222] __do_softirq+0xe8/0x2e5[ 256.489853] ? smpboot_thread_fn+0x2c/0x270[ 256.494108] run_ksoftirqd+0x2a/0x50[ 256.497747] smpboot_thread_fn+0x1c1/0x270[ 256.501907] ? __pfx_smpboot_thread_fn+0x10/0x10[ 256.506594] kthread+0xea/0x120[ 256.509785] ? __pfx_kthread+0x10/0x10[ 256.513597] ret_from_fork+0x29/0x50[ 256.517238] In fact, irqs were not disabled and napi managed to be scheduled and runwhile xsk_pool pointer was still valid, but SW ring of xdp_buff pointerswas already freed.To fix this, call ice_qvec_dis_irq() after ice_vsi_stop_tx_ring(). Alsowhile at it, remove redundant ice_clean_rx_ring() call - this is handledin ice_qp_clean_rings().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave failssyzbot reported a warning[1] where the bond device itself is a slave andwe try to enslave a non-ethernet device as the first slave which failsbut then in the error path when ether_setup() restores the bond deviceit also clears all flags. In my previous fix[2] I restored theIFF_MASTER flag, but I didn't consider the case that the bond deviceitself might also be a slave with IFF_SLAVE set, so we need to restorethat flag as well. Use the bond_ether_setup helper which does the rightthing and restores the bond's flags properly.Steps to reproduce using a nlmon dev: $ ip l add nlmon0 type nlmon $ ip l add bond1 type bond $ ip l add bond2 type bond $ ip l set bond1 master bond2 $ ip l set dev nlmon0 master bond1 $ ip -d l sh dev bond1 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we try to delete it)[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef[2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")[3] example warning: [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address [ 32.464639] bond1 (unregistering): Released all slaves [ 32.464685] ------------[ cut here ]------------ [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780 [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47 [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780 [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59 [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206 [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000 [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520 [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728 [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140 [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140 [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000 [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0 [ 32.464730] Call Trace: [ 32.464763] [ 32.464767] rtnl_dellink+0x13e/0x380 [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100 [ 32.464780] ? __rtnl_unlock+0x33/0x60 [ 32.464783] ? bpf_lsm_capset+0x10/0x10 [ 32.464786] ? security_capable+0x36/0x50 [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0 [ 32.464792] ? _copy_to_iter+0xb1/0x790 [ 32.464796] ? post_alloc_hook+0xa0/0x160 [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110 [ 32.464802] netlink_rcv_skb+0x50/0xf0 [ 32.464806] netlink_unicast+0x216/0x340 [ 32.464809] netlink_sendmsg+0x23f/0x480 [ 32.464812] sock_sendmsg+0x5e/0x60 [ 32.464815] ____sys_sendmsg+0x22c/0x270 [ 32.464818] ? import_iovec+0x17/0x20 [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90 [ 32.464823] ? do_set_pte+0xa0/0xe0 [ 32.464828] ___sys_sendmsg+0x81/0xc0 [ 32.464832] ? mod_objcg_state+0xc6/0x300 [ 32.464835] ? refill_obj_stock+0xa9/0x160 [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0 [ 32.464842] __sys_sendm---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix cleanup null-ptr deref on encap lockDuring module is unloaded while a peer tc flow is still offloaded,first the peer uplink rep profile is changed to a nic profile, and soneigh encap lock is destroyed. Next during unload, the VF reps netdevsare unregistered which causes the original non-peer tc flow to be deleted,which deletes the peer flow. The peer flow deletion detaches the encapentry and try to take the already destroyed encap lock, causing thebelow trace.Fix this by clearing peer flows during tc eswitch cleanup(mlx5e_tc_esw_cleanup()).Relevant trace:[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40[ 4316.851897] Call Trace:[ 4316.852481] [ 4316.857214] mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core][ 4316.858258] mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core][ 4316.859134] mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core][ 4316.859867] clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core][ 4316.860605] mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core][ 4316.862609] __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core][ 4316.863394] mlx5e_tc_del_flow+0x(/0x630 [mlx5_core][ 4316.864090] mlx5e_flow_put+0x5f/0x100 [mlx5_core][ 4316.864771] mlx5e_delete_flower+0x4de/0xa40 [mlx5_core][ 4316.865486] tc_setup_cb_reoffload+0x20/0x80[ 4316.865905] fl_reoffload+0x47c/0x510 [cls_flower][ 4316.869181] tcf_block_playback_offloads+0x91/0x1d0[ 4316.869649] tcf_block_unbind+0xe7/0x1b0[ 4316.870049] tcf_block_offload_cmd.isra.0+0x1ee/0x270[ 4316.879266] tcf_block_offload_unbind+0x61/0xa0[ 4316.879711] __tcf_block_put+0xa4/0x310

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: tunnels: annotate lockless accesses to dev->needed_headroomIP tunnels can apparently update dev->needed_headroomin their xmit path.This patch takes care of three tunnels xmit, and also thecore LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()helpers.More changes might be needed for completeness.BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmitread to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/i---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()When performing a stress test on SMC-R by rmmod mlx5_ib driverduring the wrk/nginx test, we found that there is a probabilityof triggering a panic while terminating all link groups.This issue dues to the race between smc_smcr_terminate_all()and smc_buf_create(). smc_smcr_terminate_allsmc_buf_create/* init */conn->sndbuf_desc = NULL;... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* panic dues to NULL sndbuf_desc */conn->sndbuf_desc = xxx;This patch tries to fix the issue by always to check the sndbuf_descbefore send any cdc msg, to make sure that no null pointer isseen during cqe processing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fs: prevent out-of-bounds array speculation when closing a file descriptorGoogle-Bug-Id: 114199369

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_make_synack() can be called from process contexttcp_rtx_synack() now could be called in process context as explained in0a375c822497 ("tcp: tcp_rtx_synack() can be called from processcontext").tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPUvariables with preemption enabled. This causes the following BUG: BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464 caller is tcp_make_synack+0x841/0xac0 Call Trace: dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. UseTCP_INC_STATS() which is safe to be called from context switch.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()When the buffer length of the recvmsg system call is 0, we got theflollowing soft lockup problem:watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:remove_wait_queue+0xb/0xc0Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThe logic in tcp_bpf_recvmsg_parser is as follows:msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; }In this case, "copied" always is 0, the infinite loop occurs.According to the Linux system call man page, 0 should be returned in thiscase. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directlyreturn. Also modify several other functions with the same problem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack modeWhen CONFIG_FRAME_POINTER is unset, the stack unwinding functionwalk_stackframe randomly reads the stack and then, when KASAN is enabled,it can lead to the following backtrace:[ 0.000000] ==================================================================[ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a[ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0[ 0.000000][ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43[ 0.000000] Hardware name: riscv-virtio,qemu (DT)[ 0.000000] Call Trace:[ 0.000000] [] walk_stackframe+0x0/0x11a[ 0.000000] [] init_param_lock+0x26/0x2a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] dump_stack_lvl+0x22/0x36[ 0.000000] [] print_report+0x198/0x4a8[ 0.000000] [] init_param_lock+0x26/0x2a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] kasan_report+0x9a/0xc8[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] desc_make_final+0x80/0x84[ 0.000000] [] stack_trace_save+0x88/0xa6[ 0.000000] [] filter_irq_stacks+0x72/0x76[ 0.000000] [] devkmsg_read+0x32a/0x32e[ 0.000000] [] kasan_save_stack+0x28/0x52[ 0.000000] [] desc_make_final+0x7c/0x84[ 0.000000] [] stack_trace_save+0x84/0xa6[ 0.000000] [] kasan_set_track+0x12/0x20[ 0.000000] [] __kasan_slab_alloc+0x58/0x5e[ 0.000000] [] __kmem_cache_create+0x21e/0x39a[ 0.000000] [] create_boot_cache+0x70/0x9c[ 0.000000] [] kmem_cache_init+0x6c/0x11e[ 0.000000] [] mm_init+0xd8/0xfe[ 0.000000] [] start_kernel+0x190/0x3ca[ 0.000000][ 0.000000] The buggy address belongs to stack of task swapper/0[ 0.000000] and is located at offset 0 in frame:[ 0.000000] stack_trace_save+0x0/0xa6[ 0.000000][ 0.000000] This frame has 1 object:[ 0.000000] [32, 56) 'c'[ 0.000000][ 0.000000] The buggy address belongs to the physical page:[ 0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07[ 0.000000] flags: 0x1000(reserved|zone=0)[ 0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000[ 0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff[ 0.000000] page dumped because: kasan: bad access detected[ 0.000000][ 0.000000] Memory state around the buggy address:[ 0.000000] ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] >ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3[ 0.000000] ^[ 0.000000] ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ==================================================================Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecisemode.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: caif: Fix use-after-free in cfusbl_device_notify()syzbot reported use-after-free in cfusbl_device_notify() [1]. Thiscauses a stack trace like below:BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 When unregistering a net device, unregister_netdevice_many_notify()sets the device's reg_state to NETREG_UNREGISTERING, calls notifierswith NETDEV_UNREGISTER, and adds the device to the todo list.Later on, devices in the todo list are processed by netdev_run_todo().netdev_run_todo() waits devices' reference count become 1 whilerebdoadcasting NETDEV_UNREGISTER notification.When cfusbl_device_notify() is called with NETDEV_UNREGISTER multipletimes, the parent device might be freed. This could cause UAF.Processing NETDEV_UNREGISTER multiple times also causes inbalance ofreference count for the module.This patch fixes the issue by accepting only first NETDEV_UNREGISTERnotification.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()ila_xlat_nl_cmd_get_mapping() generates an empty skb,triggerring a recent sanity check [1].Instead, return an error code, so that user spacecan get it.[1]skb_assert_lenWARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156Modules linked in:CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_assert_len include/linux/skbuff.h:2527 [inline]pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156lr : skb_assert_len include/linux/skbuff.h:2527 [inline]lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156sp : ffff80001e0d6c40x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000eCall trace:skb_assert_len include/linux/skbuff.h:2527 [inline]__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156dev_queue_xmit include/linux/netdevice.h:3033 [inline]__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380nlmsg_unicast include/net/netlink.h:1099 [inline]genlmsg_unicast include/net/genetlink.h:433 [inline]genlmsg_reply include/net/genetlink.h:443 [inline]ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:714 [inline]sock_sendmsg net/socket.c:734 [inline]____sys_sendmsg+0x558/0x844 net/socket.c:2479___sys_sendmsg net/socket.c:2533 [inline]__sys_sendmsg+0x26c/0x33c net/socket.c:2562__do_sys_sendmsg net/socket.c:2571 [inline]__se_sys_sendmsg net/socket.c:2569 [inline]__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591irq event stamp: 136484hardirqs last enabled at (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345hardirqs last disabled at (136484): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405softirqs last enabled at (136418): [] softirq_ha---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-2193 Severity: Moderate CVSS3 score: 5.5

Description: A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-22365 Severity: Moderate CVSS3 score: 5.5

Description: linux-pam (aka Linux PAM) before 1.6.0 allows attackers to cause a denial of service (blocked login process) via mkfifo because the openat call (for protect_dir) lacks O_DIRECTORY.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
pam > 0-0 (version in image is 1.3.0-150000.6.86.1).

CVE-2024-23849 Severity: Moderate CVSS3 score: 5.5

Description: In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-24860 Severity: Moderate CVSS3 score: 5.5

Description: A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix illegal rmb_desc access in SMC-D connection dumpA crash was found when dumping SMC-D connections. It can be reproducedby following steps:- run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76It is possible that the connection is in process of being establishedwhen we dump it. Assumed that the connection has been registered in alink group by smc_conn_create() but the rmb_desc has not yet beeninitialized by smc_buf_create(), thus causing the illegal access toconn->rmb_desc. So fix it by checking before dump.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26625 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: call sock_orphan() at release timesyzbot reported an interesting trace [1] caused by a stale sk->sk_wqpointer in a closed llc socket.In commit ff7b11aa481f ("net: socket: set sock->sk to NULL aftercalling proto_ops::release()") Eric Biggers hinted that some protocolsare missing a sock_orphan(), we need to perform a full audit.In net-next, I plan to clear sock->sk from sock_orphan() andamend Eric patch to add a warning.[1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bFreed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Move scsi_host_busy() out of host lock for waking up EH handlerInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with hostlock every time for deciding if error handler kthread needs to be waken up.This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requestsIf recovery is triggered in case that all requests are in-flight, eachscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is calledfor the last in-flight request, scsi_host_busy() has been run for (N * M -1) times, and request has been iterated for (N*M - 1) * (N * M) times.If both N and M are big enough, hard lockup can be triggered on acquiringhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).Fix the issue by calling scsi_host_busy() outside the host lock. We don'tneed the host lock for getting busy count because host the lock nevercovers that.[mkp: Drop unnecessary 'busy' variables pointed out by Bart]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26631 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_workidev->mc_ifc_count can be written over without proper locking.Originally found by syzbot [1], fix this issue by encapsulating callsto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) withmutex_lock() and mutex_unlock() accordingly as these functionsshould only be called with mc_lock per their declarations.[1]BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_workwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ...write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26636 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: make llc_ui_sendmsg() more robust against bonding changessyzbot was able to trick llc_ui_sendmsg(), allocating an skb with noheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]Like some others, llc_ui_sendmsg() releases the socket lock beforecalling sock_alloc_send_skb().Then it acquires it again, but does not redo all the sanity checksthat were performed.This fix:- Uses LL_RESERVED_SPACE() to reserve space.- Check all conditions again after socket lock is held again.- Do not account Ethernet header for mtu limitation.[1]skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 !Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203sp : ffff800096f97000x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261cex17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add sanity checks to rx zerocopyTCP rx zerocopy intent is to map pages initially allocatedfrom NIC drivers, not pages owned by a fs.This patch adds to can_map_frag() these additional checks:- Page must not be a compound one.- page->mapping must be NULL.This fixes the panic reported by ZhangPeng.syzbot was able to loopback packets built with sendfile(),mapping pages owned by an ext4 file to TCP rx zerocopy.r3 = socket$inet_tcp(0x2, 0x1, 0x0)mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)r4 = socket$inet_tcp(0x2, 0x1, 0x0)bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)fallocate(r5, 0x0, 0x0, 0x85b8)sendfile(r4, r5, 0x0, 0x8ba0)getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Ensure visibility when inserting an element into tracing_mapRunning the following two commands in parallel on a multi-processorAArch64 machine can sporadically produce an unexpected warning aboutduplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)The warning looks as follows:[ 2911.172474] ------------[ cut here ]------------[ 2911.173111] Duplicates detected: 1[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408[ 2911.185310] sp : ffff8000a1513900[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480[ 2911.194259] Call trace:[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408[ 2911.195220] hist_show+0x124/0x800[ 2911.195692] seq_read_iter+0x1d4/0x4e8[ 2911.196193] seq_read+0xe8/0x138[ 2911.196638] vfs_read+0xc8/0x300[ 2911.197078] ksys_read+0x70/0x108[ 2911.197534] __arm64_sys_read+0x24/0x38[ 2911.198046] invoke_syscall+0x78/0x108[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8[ 2911.199157] do_el0_svc+0x28/0x40[ 2911.199613] el0_svc+0x40/0x178[ 2911.200048] el0t_64_sync_handler+0x13c/0x158[ 2911.200621] el0t_64_sync+0x1a8/0x1b0[ 2911.201115] ---[ end trace 0000000000000000 ]---The problem appears to be caused by CPU reordering of writes issued from__tracing_map_insert().The check for the presence of an element with a given key in thisfunction is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ...The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"stores may become visible in the reversed order on another CPU. Thissecond CPU might then incorrectly determine that a new key doesn't matchan already present val->key and subse---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xhci: handle isoc Babble and Buffer Overrun events properlyxHCI 4.9 explicitly forbids assuming that the xHC has released itsownership of a multi-TRB TD when it reports an error on one of theearly TRBs. Yet the driver makes such assumption and releases the TD,allowing the remaining TRBs to be freed or overwritten by new TDs.The xHC should also report completion of the final TRB due to its IOCflag being set by us, regardless of prior errors. This event cannotbe recognized if the TD has already been freed earlier, resulting in"Transfer event TRB DMA ptr not part of current TD" error message.Fix this by reusing the logic for processing isoc Transaction Errors.This also handles hosts which fail to report the final completion.Fix transfer length reporting on Babble errors. They may be caused bydevice malfunction, no guarantee that the buffer has been filled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Implement bounds check for stream encoder creation in DCN301'stream_enc_regs' array is an array of dcn10_stream_enc_registersstructures. The array is initialized with four elements, correspondingto the four calls to stream_enc_regs() in the array initializer. Thismeans that valid indices for this array are 0, 1, 2, and 3.The error message 'stream_enc_regs' 4 <= 5 below, is indicating thatthere is an attempt to access this array with an index of 5, which isout of bounds. This could lead to undefined behaviorHere, eng_id is used as an index to access the stream_enc_regs array. Ifeng_id is 5, this would result in an out-of-bounds access on thestream_enc_regs array.Thus fixing Buffer overflow error in dcn301_stream_encoder_createreported by Smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26662 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()''panel_cntl' structure used to control the display panel could be null,dereferencing it could lead to a null pointer access.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Fix out-of-bounds memory accessFix a bug that pdata->cpu_map[] is set before out-of-bounds check.The problem might be triggered on systems with more than 128 cores perpackage.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: flower: Fix chain template offloadWhen a qdisc is deleted from a net device the stack instructs theunderlying driver to remove its flow offload callback from theassociated filter block using the 'FLOW_BLOCK_UNBIND' command. The stackthen continues to replay the removal of the filters in the block forthis driver by iterating over the chains in the block and invoking the'reoffload' operation of the classifier being used. In turn, theclassifier in its 'reoffload' operation prepares and emits a'FLOW_CLS_DESTROY' command for each filter.However, the stack does not do the same for chain templates and theunderlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command whena qdisc is deleted. This results in a memory leak [1] which can bereproduced using [2].Fix by introducing a 'tmplt_reoffload' operation and have the stackinvoke it with the appropriate arguments as part of the replay.Implement the operation in the sole classifier that supports chaintemplates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'command based on whether a flow offload callback is being bound to afilter block or being unbound from one.As far as I can tell, the issue happens since cited commit whichreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()in __tcf_block_put(). The order cannot be reversed as the filter blockis expected to be freed after flushing all the chains.[1]unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc+0x4e/0x90 [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [] ___sys_sendmsg+0x13a/0x1e0 [] __sys_sendmsg+0x11c/0x1f0 [] do_syscall_64+0x40/0xe0unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc_node+0x51/0x90 [] kvmalloc_node+0xa6/0x1f0 [] bucket_table_alloc.isra.0+0x83/0x460 [] rhashtable_init+0x43b/0x7c0 [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80[2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26671 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix IO hang from sbitmap wakeup raceIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-orderedwith the following blk_mq_get_driver_tag() in case of getting drivertag failure.Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observethe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantimeblk_mq_mark_tag_wait() can't get driver tag successfully.This issue can be reproduced by running the following test in loop, andfio hang can be observed in < 30min when running it on my test VMin laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaioFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), whichis just fine in case of running out of tag.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26673 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.- Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp_async: limit MRU to 64Ksyzbot triggered a warning [1] in __alloc_pages():WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)[1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543Modules linked in:CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events_unbound flush_to_ldiscpstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537sp : ffff800093967580x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003fx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: Fix DMA mapping for PTP hwts ringFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytesfor PTP HWTS ring but then generic aq_ring_free() does not take thisinto account.Create and use a specific function to free HWTS ring to fix thisissue.Trace:[ 215.351607] ------------[ cut here ]------------[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes][ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360...[ 215.581176] Call Trace:[ 215.583632] [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df[ 215.594497] ? debug_dma_free_coherent+0x196/0x210[ 215.599305] ? check_unmap+0xa6f/0x2360[ 215.603147] ? __warn+0xca/0x1d0[ 215.606391] ? check_unmap+0xa6f/0x2360[ 215.610237] ? report_bug+0x1ef/0x370[ 215.613921] ? handle_bug+0x3c/0x70[ 215.617423] ? exc_invalid_op+0x14/0x50[ 215.621269] ? asm_exc_invalid_op+0x16/0x20[ 215.625480] ? check_unmap+0xa6f/0x2360[ 215.629331] ? mark_lock.part.0+0xca/0xa40[ 215.633445] debug_dma_free_coherent+0x196/0x210[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0[ 215.648060] dma_free_attrs+0x6d/0x130[ 215.651834] aq_ring_free+0x193/0x290 [atlantic][ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]...[ 216.127540] ---[ end trace 6467e5964dd2640b ]---[ 216.132160] DMA-API: Mapped at:[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0[ 216.132165] dma_alloc_attrs+0xf5/0x1b0[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic][ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic][ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: xgmac: fix handling of DPP safety error for DMA channelsCommit 56e58d6c8a56 ("net: stmmac: Implement Safety Features inXGMAC core") checks and reports safety errors, but leaves theData Path Parity Errors for each channel in DMA unhandled at all, lead toa storm of interrupt.Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential bug in end_buffer_async_writeAccording to a syzbot report, end_buffer_async_write(), which handles thecompletion of block device writes, may detect abnormal condition of thebuffer async_write flag and cause a BUG_ON failure when using nilfs2.Nilfs2 itself does not use end_buffer_async_write(). But, the async_writeflag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issuewith race condition of competition between segments for dirty blocks") asa means of resolving double list insertion of dirty blocks innilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and theresulting crash.This modification is safe as long as it is used for file data and b-treenode blocks where the page caches are independent. However, it wasirrelevant and redundant to also introduce async_write for segment summaryand super root blocks that share buffers with the backing device. Thisled to the possibility that the BUG_ON check in end_buffer_async_writewould fail as described above, if independent writebacks of the backingdevice occurred in parallel.The use of async_write for segment summary buffers has already beenremoved in a previous change.Fix this issue by removing the manipulation of the async_write flag forthe remaining super root block buffer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_lockedThe SEV platform device can be shutdown with a null psp_master,e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)[ 137.162647] ccp 0000:23:00.1: no command queues available[ 137.170598] ccp 0000:23:00.1: sev enabled[ 137.174645] ccp 0000:23:00.1: psp enabled[ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI[ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7][ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311[ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180[ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c[ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216[ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e[ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0[ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66[ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28[ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8[ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000[ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0[ 137.182693] Call Trace:[ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80[ 137.182693] ? __die_body+0x24/0x70[ 137.182693] ? die_addr+0x4b/0x80[ 137.182693] ? exc_general_protection+0x126/0x230[ 137.182693] ? asm_exc_general_protection+0x2b/0x30[ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180[ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80[ 137.182693] sev_dev_destroy+0x49/0x100[ 137.182693] psp_dev_destroy+0x47/0xb0[ 137.182693] sp_destroy+0xbb/0x240[ 137.182693] sp_pci_remove+0x45/0x60[ 137.182693] pci_device_remove+0xaa/0x1d0[ 137.182693] device_remove+0xc7/0x170[ 137.182693] really_probe+0x374/0xbe0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] __driver_probe_device+0x199/0x460[ 137.182693] driver_probe_device+0x4e/0xd0[ 137.182693] __driver_attach+0x191/0x3d0[ 137.182693] ? __pfx___driver_attach+0x10/0x10[ 137.182693] bus_for_each_dev+0x100/0x190[ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10[ 137.182693] ? __kasan_check_read+0x15/0x20[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? _raw_spin_unlock+0x27/0x50[ 137.182693] driver_attach+0x41/0x60[ 137.182693] bus_add_driver+0x2a8/0x580[ 137.182693] driver_register+0x141/0x480[ 137.182693] __pci_register_driver+0x1d6/0x2a0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10[ 137.182693] sp_pci_init+0x22/0x30[ 137.182693] sp_mod_init+0x14/0x30[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10[ 137.182693] do_one_initcall+0xd1/0x470[ 137.182693] ? __pfx_do_one_initcall+0x10/0x10[ 137.182693] ? parameq+0x80/0xf0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? __kmalloc+0x3b0/0x4e0[ 137.182693] ? kernel_init_freeable+0x92d/0x1050[ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] kernel_init_freeable+0xa64/0x1050[ 137.182693] ? __pfx_kernel_init+0x10/0x10[ 137.182693] kernel_init+0x24/0x160[ 137.182693] ? __switch_to_asm+0x3e/0x70[ 137.182693] ret_from_fork+0x40/0x80[ 137.182693] ? __pfx_kernel_init+0x1---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()Syzbot reported a hang issue in migrate_pages_batch() called by mbind()and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.While migrate_pages_batch() locks a folio and waits for the writeback tocomplete, the log writer thread that should bring the writeback tocompletion picks up the folio being written back innilfs_lookup_dirty_data_buffers() that it calls for subsequent logcreation and was trying to lock the folio. Thus causing a deadlock.In the first place, it is unexpected that folios/pages in the middle ofwriteback will be updated and become dirty. Nilfs2 adds a checksum toverify the validity of the log being written and uses it for recovery atmount, so data changes during writeback are suppressed. Since this isbroken, an unclean shutdown could potentially cause recovery to fail.Investigation revealed that the root cause is that the wait for writebackcompletion in nilfs_page_mkwrite() is conditional, and if the backingdevice does not require stable writes, data may be modified withoutwaiting.Fix these issues by making nilfs_page_mkwrite() wait for writeback tofinish regardless of the stable write requirement of the backing device.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26698 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix race condition between netvsc_probe and netvsc_removeIn commit ac5047671758 ("hv_netvsc: Disable NAPI before closing theVMBus channel"), napi_disable was getting called for all channels,including all subchannels without confirming if they are enabled or not.This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()has finished running but nvdev->subchan_work has not started yet.netvsc_subchan_work() -> rndis_set_subchannel() has not created thesub-channels and because of that netvsc_sc_open() is not running.netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for whichnetvsc_subchan_work did not run.netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPIcannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear theNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does theopposite.Now during netvsc_device_remove(), when napi_disable is called for thosesubchannels, napi_disable gets stuck on infinite msleep.This fix addresses this problem by ensuring that napi_disable() is notgetting called for non-enabled NAPI struct.But netif_napi_del() is still necessary for these non-enabled NAPI structfor cleanup purpose.Call trace:[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002[ 654.568030] Call Trace:[ 654.571221] [ 654.573790] __schedule+0x2d6/0x960[ 654.577733] schedule+0x69/0xf0[ 654.581214] schedule_timeout+0x87/0x140[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20[ 654.590291] msleep+0x2d/0x40[ 654.593625] napi_disable+0x2b/0x80[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc][ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc][ 654.611101] ? do_wait_intr+0xb0/0xb0[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc][ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRCRecently, we encounter kernel crash in function rm3100_common_probecaused by out of bound access of array rm3100_samp_rates (because ofunderlying hardware failures). Add boundary check to prevent out ofbound access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()Syzkaller reported [1] hitting a warning after failing to allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294...Call Trace: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649...This issue is also found in older kernels (at least up to 5.10).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid-of: fix NULL-deref on failed power upA while back the I2C HID implementation was split in an ACPI and OFpart, but the new OF driver never initialises the client pointer whichis dereferenced on power-up failures.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt, dm-verity: disable taskletsTasklets have an inherent problem with memory corruption. The functiontasklet_action_common calls tasklet_trylock, then it calls the taskletcallback and then it calls tasklet_unlock. If the tasklet callback freesthe structure that contains the tasklet or if it calls some code that mayfree it, tasklet_unlock will write into free memory.The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, butit is not a sufficient fix and the data corruption can still happen [1].There is no fix for dm-verity and dm-verity will write into free memorywith every tasklet-processed bio.There will be atomic workqueues implemented in the kernel 6.9 [2]. Theywill have better interface and they will not suffer from the memorycorruption problem.But we need something that stops the memory corruption now and that can bebackported to the stable kernels. So, I'm proposing this commit thatdisables tasklets in both dm-crypt and dm-verity. This commit doesn'tremove the tasklet support, because the tasklet code will be reused whenatomic workqueues will be implemented.[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/[2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix possible use-after-free and null-ptr-derefThe pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26742 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix disable_managed_interruptsCorrect blk-mq registration issue with module parameterdisable_managed_interrupts enabled.When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs toregister with blk-mq using blk_mq_map_queues(). The driver is currentlycalling blk_mq_pci_map_queues() which results in a stack trace and possiblyundefined behavior.Stack Trace:[ 7.860089] scsi host2: smartpqi[ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0[ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse[ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1[ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022[ 7.963026] Workqueue: events work_for_cpu_fn[ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0[ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54[ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216[ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010[ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310[ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00[ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000[ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8[ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000[ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0[ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 8.172818] PKRU: 55555554[ 8.172819] Call Trace:[ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310[ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245[ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi][ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi][ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi][ 8.323286] local_pci_probe+0x42/0x80[ 8.337855] work_for_cpu_fn+0x16/0x20[ 8.351193] process_one_work+0x1a7/0x360[ 8.364462] ? create_worker+0x1a0/0x1a0[ 8.379252] worker_thread+0x1ce/0x390[ 8.392623] ? create_worker+0x1a0/0x1a0[ 8.406295] kthread+0x10a/0x120[ 8.418428] ? set_kthread_struct+0x50/0x50[ 8.431532] ret_from_fork+0x1f/0x40[ 8.444137] ---[ end trace 1bf0173d39354506 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Support specifying the srpt_service_guid parameterMake loading ib_srpt with this parameter set work. The current behavior isthat setting that parameter while loading the ib_srpt kernel moduletriggers the following kernel crash:BUG: kernel NULL pointer dereference, address: 0000000000000000Call Trace: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fix memory double free when handle zero packet829 if (request->complete) {830 spin_unlock(&priv_dev->lock);831 usb_gadget_giveback_request(&priv_ep->endpoint,832 request);833 spin_lock(&priv_dev->lock);834 }835836 if (request->buf == priv_dev->zlp_buf)837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);Driver append an additional zero packet request when queue a packet, whichlength mod max packet size is 0. When transfer complete, run to line 831,usb_gadget_giveback_request() will free this requestion. 836 condition istrue, so cdns3_gadget_ep_free_request() free this request again.Log:[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.140696][ T150][ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]Add check at line 829, skip call usb_gadget_giveback_request() if it isadditional zero length packet request. Needn't callusb_gadget_giveback_request() because it is allocated in this driver.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26754 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()The gtp_net_ops pernet operations structure for the subsystem must beregistered before registering the generic netlink family.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:general protection fault, probably for non-canonical address0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74RSP: 0018:ffff888014107220 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt: don't modify the data when using authenticated encryptionIt was said that authenticated encryption could produce invalid tag whenthe data that is being encrypted is modified [1]. So, fix this problem bycopying the data into the clone bio first and then encrypt them inside theclone bio.This may reduce performance, but it is needed to prevent the user fromcorrupting the device by writing data with O_DIRECT and modifying them atthe same time.[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Add some null pointer checks to the edma_probedevm_kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()Places the logic for checking if the group's block bitmap is corrupt underthe protection of the group lock to avoid allocating blocks from the groupwith a corrupted block bitmap.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26775 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:aoe: avoid potential deadlock at set_capacityMove set_capacity() outside of the section procected by (&d->lock).To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ----[1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); [4] lock(&d->lock); *** DEADLOCK ***Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.In this situation an attempt to acquire [4]lock(&d->lock) fromaoecmd_cfg_rsp() will lead to deadlock.So the simplest solution is breaking lock dependency[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()outside.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detectedReturn IRQ_NONE from the interrupt handler when no interrupt wasdetected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: sis: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn't check the value of pixclock,it may cause divide-by-zero error.In sisfb_check_var(), var->pixclock is used as a divisor to caculatedrate before it is checked against zero. Fix this by checking itat the beginning.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix race condition on enabling fast-xmitfast-xmit must only be enabled after the sta has been uploaded to the driver,otherwise it could end up passing the not-yet-uploaded sta via drv_tx callsto the driver, leading to potential crashes because of uninitialized drv_privdata.Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: mmci: stm32: fix DMA API overlapping mappings warningTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,overlapping mappings aren't supportedWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568add_dma_entry+0x234/0x2f4Modules linked in:CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)Workqueue: events_freezable mmc_rescanCall trace:add_dma_entry+0x234/0x2f4debug_dma_map_sg+0x198/0x350__dma_map_sg_attrs+0xa0/0x110dma_map_sg_attrs+0x10/0x2csdmmc_idma_prep_data+0x80/0xc0mmci_prep_data+0x38/0x84mmci_start_data+0x108/0x2dcmmci_request+0xe4/0x190__mmc_start_request+0x68/0x140mmc_start_request+0x94/0xc0mmc_wait_for_req+0x70/0x100mmc_send_tuning+0x108/0x1acsdmmc_execute_tuning+0x14c/0x210mmc_execute_tuning+0x48/0xecmmc_sd_init_uhs_card.part.0+0x208/0x464mmc_sd_init_card+0x318/0x89cmmc_attach_sd+0xe4/0x180mmc_rescan+0x244/0x320DMA API debug brings to light leaking dma-mappings as dma_map_sg anddma_unmap_sg are not correctly balanced.If an error occurs in mmci_cmd_irq function, only mmci_dma_errorfunction is called and as this API is not managed on stm32 variant,dma_unmap_sg is never called in this error path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26788 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: init irq after reg initializationInitialize the qDMA irqs after the registers are configured so thatinterrupts that may have been pending from a primary kernel don't getprocessed by the irq handler before it is ready to and cause panic withthe following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26790 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned readThere is chip (ls1028a) errata:The SoC may hang on 16 byte unaligned read transactions by QDMA.Unaligned read transactions initiated by QDMA may stall in the NOC(Network On-Chip), causing a deadlock condition. Stalled transactions willtrigger completion timeouts in PCIe controller.Workaround:Enable prefetch by setting the source descriptor prefetchable bit( SD[PF] = 1 ).Implement this workaround.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: dev-replace: properly validate device namesThere's a syzbot report that device name buffers passed to devicereplace are not properly checked for string termination which could leadto a read out of bounds in getname_kernel().Add a helper that validates both source and target device name buffers.For devid as the source initialize the buffer to empty string in casesomething tries to read it later.This was originally analyzed and fixed in a different way by Edward AdamDavis (see links).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26793 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_newlink()The gtp_link_ops operations structure for the subsystem must beregistered after registering the gtp_net_ops pernet operations structure.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:[ 1010.702740] gtp: GTP module unloaded[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f][ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0[ 1010.715968] PKRU: 55555554[ 1010.715972] Call Trace:[ 1010.715985] ? __die_body.cold+0x1a/0x1f[ 1010.715995] ? die_addr+0x43/0x70[ 1010.716002] ? exc_general_protection+0x199/0x2f0[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp][ 1010.716042] __rtnl_newlink+0x1063/0x1700[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0[ 1010.716076] ? __kernel_text_address+0x56/0xa0[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30[ 1010.716098] ? arch_stack_walk+0x9e/0xf0[ 1010.716106] ? stack_trace_save+0x91/0xd0[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170[ 1010.716121] ? __lock_acquire+0x15c5/0x5380[ 1010.716139] ? mark_held_locks+0x9e/0xe0[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700[ 1010.716160] rtnl_newlink+0x69/0xa0[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716179] ? lock_acquire+0x1fe/0x560[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50[ 1010.716196] netlink_rcv_skb+0x14d/0x440[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716208] ? netlink_ack+0xab0/0xab0[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50[ 1010.716226] ? __virt_addr_valid+0x30b/0x590[ 1010.716233] netlink_unicast+0x54b/0x800[ 1010.716240] ? netlink_attachskb+0x870/0x870[ 1010.716248] ? __check_object_size+0x2de/0x3b0[ 1010.716254] netlink_sendmsg+0x938/0xe40[ 1010.716261] ? netlink_unicast+0x800/0x800[ 1010.716269] ? __import_iovec+0x292/0x510[ 1010.716276] ? netlink_unicast+0x800/0x800[ 1010.716284] __sock_sendmsg+0x159/0x190[ 1010.716290] ____sys_sendmsg+0x712/0x880[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270[ 1010.716309] ? lock_acquire+0x1fe/0x560[ 1010.716315] ? drain_array_locked+0x90/0x90[ 1010.716324] ___sys_sendmsg+0xf8/0x170[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170[ 1010.716337] ? lockdep_init_map---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: always restore the old font data in fbcon_do_set_font()Commit a5a923038d70 (fbdev: fbcon: Properly revert changes whenvc_resize() failed) started restoring old font data upon failure (ofvc_resize()). But it performs so only for user fonts. It means that the"system"/internal fonts are not restored at all. So in result, the veryfirst call to fbcon_do_set_font() performs no restore at all uponfailing vc_resize().This can be reproduced by Syzkaller to crash the system on the nextinvocation of font_get(). It's rather hard to hit the allocation failurein vc_resize() on the first font_set(), but not impossible. Esp. iffault injection is used to aid the execution/failure. It wasdemonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ...So restore the font data in any case, not only for user fonts. Note thelater 'if' is now protected by 'old_userfont' and not 'old_data' as thelatter is always set now. (And it is supposed to be non-NULL. Otherwisewe would see the bug above again.)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Avoid potential use-after-free in hci_error_resetWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlyingBT controller is not responding, the GPIO reset mechanism wouldfree the hci_dev and lead to a use-after-free in hci_error_reset.Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30This patch holds the reference count on the hci_dev while processinga HCI_EV_HARDWARE_ERROR event to avoid potential crash.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:stmmac: Clear variable when destroying workqueueCurrently when suspending driver and stopping workqueue it is checked whetherworkqueue is not NULL and if so, it is destroyed.Function destroy_workqueue() does drain queue and does clear variable, butit does not set workqueue variable to NULL. This can cause kernel/modulepanic if code attempts to clear workqueue that was not initialized.This scenario is possible when resuming suspended driver in stmmac_resume(),because there is no handling for failed stmmac_hw_setup(),which can fail and return if DMA engine has failed to initialize,and workqueue is initialized after DMA engine.Should DMA engine fail to initialize, resume will proceed normally,but interface won't work and TX queue will eventually timeout,causing 'Reset adapter' error.This then does destroy workqueue during reset process.And since workqueue is initialized after DMA engine and can be skipped,it will cause kernel/module panic.To secure against this possible crash, set workqueue variable to NULL whendestroying workqueue.Log/backtrace from crash goes as follows:[88.031977]------------[ cut here ]------------[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[ end trace e70de432e4d5c2c0 ]---[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.[88.036359]------------[ cut here ]------------[88.036519]Call trace:[88.036523] flush_workqueue+0x3e4/0x430[88.036528] drain_workqueue+0xc4/0x160[88.036533] destroy_workqueue+0x40/0x270[88.036537] stmmac_fpe_stop_wq+0x4c/0x70[88.036541] stmmac_release+0x278/0x280[88.036546] __dev_close_many+0xcc/0x158[88.036551] dev_close_many+0xbc/0x190[88.036555] dev_close.part.0+0x70/0xc0[88.036560] dev_close+0x24/0x30[88.036564] stmmac_service_task+0x110/0x140[88.036569] process_one_work+0x1d8/0x4a0[88.036573] worker_thread+0x54/0x408[88.036578] kthread+0x164/0x170[88.036583] ret_from_fork+0x10/0x20[88.036588]---[ end trace e70de432e4d5c2c1 ]---[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets' ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix kernel-infoleak-after-free in __skb_datagram_itersyzbot reported the following uninit-value access issue [1]:netlink_to_full_skb() creates a new `skb` and puts the `skb->data`passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The datasize is specified as `len` and passed to skb_put_data(). This `len`is based on `skb->end` that is not data offset but buffer offset. The`skb->end` contains data and tailroom. Since the tailroom is notinitialized when the new `skb` created, KMSAN detects uninitializedmemory area when copying the data.This patch resolved this issue by correct the len from `skb->end` to`skb->len`, which is the actual data offset.BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Both cadence-quadspi ->runtime_suspend() and ->runtime_resume()implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev);This obviously cannot be correct, unless "struct cqspi_st" is thefirst member of " struct spi_controller", or the other way around, butit is not the case. "struct spi_controller" is allocated bydevm_spi_alloc_host(), which allocates an extra amount of memory forprivate data, used to store "struct cqspi_st".The ->probe() function of the cadence-quadspi driver then sets thedevice drvdata to store the address of the "struct cqspi_st"structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev);is correct, but: struct spi_controller *host = dev_get_drvdata(dev);is not, as it makes "host" point not to a "struct spi_controller" butto the same "struct cqspi_st" structure as above.This obviously leads to bad things (memory corruption, kernel crashes)directly during ->probe(), as ->probe() enables the device using PMruntime, leading the ->runtime_resume() hook being called, which inturns calls spi_controller_resume() with the wrong pointer.This has at least been reported [0] to cause a kernel crash, but theexact behavior will depend on the memory contents.[0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/This issue potentially affects all platforms that are currently usingthe cadence-quadspi driver.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: set correct id, uid and cruid for multiuser automountsWhen uid, gid and cruid are not specified, we need to dynamicallyset them into the filesystem context used for automounting otherwisethey'll end up reusing the values from the parent mount.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: free rx_data_reassembly skb on NCI device cleanuprx_data_reassembly skb is stored during NCI data exchange for processingfragmented packets. It is dropped only when the last fragment is processedor when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.However, the NCI device may be deallocated before that which leads to skbleak.As by design the rx_data_reassembly skb is bound to the NCI device andnothing prevents the device to be freed before the skb is processed insome way and cleaned, free it on the NCI device cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: ir_toy: fix a memleak in irtoy_txWhen irtoy_command fails, buf should be freed since it is allocated byirtoy_tx, or there is a memleak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not allow untrusted VF to remove administratively set MACCurrently when PF administratively sets VF's MAC address and the VFis put down (VF tries to delete all MACs) then the MAC is removedfrom MAC filters and primary VF MAC is zeroed.Do not allow untrusted VF to remove primary MAC when it was setadministratively by PF.Reproducer:1) Create VF2) Set VF interface up3) Administratively set the VF's MAC4) Put VF interface down[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs[root@host ~]# ip link set enp2s0f0v0 up[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off[root@host ~]# ip link set enp2s0f0v0 down[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix memory leak in dm_sw_fini()After destroying dmub_srv, the memory associated with it isnot freed, causing a memory leak:unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [] kmalloc_trace+0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300Fix this by freeing dmub_srv after destroying it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26838 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix KASAN issue with taskletKASAN testing revealed the following issue assocated with freeing an IRQ.[50006.466686] Call Trace:[50006.466691] [50006.489538] dump_stack+0x5c/0x80[50006.493475] print_address_description.constprop.6+0x1a/0x150[50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.511644] kasan_report.cold.11+0x7f/0x118[50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma][50006.528232] irdma_process_ceq+0xb2/0x400 [irdma][50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma][50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma][50006.545306] tasklet_action_common.isra.14+0x148/0x2c0[50006.551096] __do_softirq+0x1d0/0xaf8[50006.555396] irq_exit_rcu+0x219/0x260[50006.559670] irq_exit+0xa/0x20[50006.563320] smp_apic_timer_interrupt+0x1bf/0x690[50006.568645] apic_timer_interrupt+0xf/0x20[50006.573341] The issue is that a tasklet could be pending on another core racingthe delete of the irq.Fix by insuring any scheduled tasklet is killed after deleting theirq.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26843 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efi: runtime: Fix potential overflow of soft-reserved region sizemd_size will have been narrowed if we have >= 4GB worth of pages in asoft-reserved region.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: Add protection for bmp length out of rangeUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shiftsthat are out of bounds for their data type.vmlinux get_bitmap(b=75) + 712vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216vmlinux DecodeRasMessage() + 304vmlinux ras_help() + 684vmlinux nf_confirm() + 188Due to abnormal data in skb->data, the extension bitmap lengthexceeds 32 when decoding ras message then uses the length to makea shift operation. It will change into negative after several loop.UBSAN load could detect a negative shift as an undefined behaviourand reports exception.So we add the protection to avoid the length exceeding 32. Or elseit will return out of range error and stop decoding.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igc: avoid returning frame twice in XDP_REDIRECTWhen a frame can not be transmitted in XDP_REDIRECT(e.g. due to a full queue), it is necessary to freeit by calling xdp_return_frame_rx_napi.However, this is the responsibility of the caller ofthe ndo_xdp_xmit (see for example bq_xmit_all inkernel/bpf/devmap.c) and thus calling it insideigc_xdp_xmit (which is the ndo_xdp_xmit of the igcdriver) as well will lead to memory corruption.In fact, bq_xmit_all expects that it can return allframes after the last successfully transmitted one.Therefore, break for the first not transmitted frame,but do not call xdp_return_frame_rx_napi in igc_xdp_xmit.This is equally implemented in other Intel driverssuch as the igb.There are two alternatives to this that were rejected:1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets).2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped.The memory corruption can be reproduced withthe following script which leads to a kernel panicafter a few seconds. It basically generates moretraffic than a i225 NIC can transmit and pushes itvia XDP_REDIRECT from a virtual interface to thephysical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()The function ice_bridge_setlink() may encounter a NULL pointer dereferenceif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequentlyin nla_for_each_nested(). To address this issue, add a check to ensure thatbr_spec is not NULL before proceeding with the nested attribute iteration.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sparx5: Fix use after free inside sparx5_del_mact_entryBased on the static analyzis of the code it looks like when an entryfrom the MAC table was removed, the entry was still used after beingfreed. More precise the vid of the mac_entry was used after callingdevm_kfree on the mac_entry.The fix consists in first using the vid of the mac_entry to delete theentry from the HW and after that to free it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: make sure to pull inner header in geneve_rx()syzbot triggered a bug in geneve_rx() [1]Issue is similar to the one I fixed in commit 8d975c15c0cd("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.[1]BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/bnx2x: Prevent access to a freed page in page_poolFix race condition leading to system crash during EEH error handlingDuring EEH error recovery, the bnx2x driver's transmit timeout logiccould cause a race condition when handling reset tasks. Thebnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()SGEs are freed using bnx2x_free_rx_sge_range(). However, this couldoverlap with the EEH driver's attempt to reset the device usingbnx2x_io_slot_reset(), which also tries to free SGEs. This racecondition can result in system crashes due to accessing freed memorylocations in bnx2x_free_rx_sge()799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,800 struct bnx2x_fastpath *fp, u16 index)801 {802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];803 struct page *page = sw_buf->page;....where sw_buf was set to NULL after the call to dma_unmap_page()by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64To solve this issue, we need to verify page pool allocations beforefreeing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: receive: annotate data-race around receiving_counter.counterSyzkaller with KCSAN identified a data-race issue when accessingkeypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in hsr_get_node()KMSAN reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023=====================================================If the packet type ID field in the Ethernet header is either ETH_P_PRP orETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()reads an invalid value as a sequence number. This causes the above issue.This patch fixes the issue by returning NULL if the Ethernet header is notfollowed by an HSR tag.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: lpspi: Avoid potential use-after-free in probe()fsl_lpspi_probe() is allocating/disposing memory manually withspi_alloc_host()/spi_alloc_target(), but usesdevm_spi_register_controller(). In case of error after the latter call thememory will be explicitly freed in the probe function byspi_controller_put() call, but used afterwards by "devm" management outsideprobe() (spi_unregister_controller() <- devm_spi_unregister() below).Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070...Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102A call to listxattr() with a buffer size = 0 returns the actualsize of the buffer needed for a subsequent call. When size > 0,nfs4_listxattr() does not return an error because eithergeneric_listxattr() or nfs4_listxattr_nfs4_label() consumesexactly all the bytes then size is 0 when callingnfs4_listxattr_nfs4_user() which then triggers the followingkernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',thus calling lisxattr() with size = 16 will trigger the bug.Add check on nfs4_listxattr() to return ERANGE error when it iscalled with size > 0 and the return value is greater than size.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Do not register event handler until srpt device is fully setupUpon rare occasions, KASAN reports a use-after-free Writein srpt_refresh_port().This seems to be because an event handler is registered before thesrpt device is fully setup and a race condition upon error may leave apartially setup event handler in place.Instead, only register the event handler after srpt device initializationis complete.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26874 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipIt's possible that mtk_crtc->event is NULL inmtk_drm_crtc_finish_page_flip().pending_needs_vblank value is set by mtk_crtc->event, but inmtk_drm_crtc_atomic_flush(), it's is not guarded by the samelock in mtk_drm_finish_page_flip(), thus a race condition happens.Consider the following case:CPU1 CPU2step 1:mtk_drm_crtc_atomic_begin()mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event)step 2:mtk_crtc_ddp_irq ->mtk_drm_finish_page_flip:lockmtk_crtc->event set to null,pending_needs_vblank set to falseunlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointerInstead of guarding the entire mtk_drm_crtc_atomic_flush(), it's moreefficient to just check if mtk_crtc->event is null before use.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26876 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: adv7511: fix crash on irq during probeMoved IRQ registration down to end of adv7511_probe().If an IRQ already is pending during adv7511_probe(before adv7511_cec_init) then cec_received_msg_tscould crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: meson: Add missing clocks to axg_clk_regmapsSome clocks were missing from axg_clk_regmaps, which caused kernel panicduring cat /sys/kernel/debug/clk/clk_summary[ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc...[ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 57.436900] pc : regmap_read+0x1c/0x88[ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0[ 57.445611] sp : ffff800082f1b690[ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70[ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000[ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000[ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff[ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000[ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100[ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24[ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710[ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000[ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000[ 57.519615] Call trace:[ 57.522030] regmap_read+0x1c/0x88[ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0[ 57.530050] clk_core_is_enabled+0x44/0x120[ 57.534190] clk_summary_show_subtree+0x154/0x2f0[ 57.538847] clk_summary_show_subtree+0x220/0x2f0[ 57.543505] clk_summary_show_subtree+0x220/0x2f0[ 57.548162] clk_summary_show_subtree+0x220/0x2f0[ 57.552820] clk_summary_show_subtree+0x220/0x2f0[ 57.557477] clk_summary_show_subtree+0x220/0x2f0[ 57.562135] clk_summary_show_subtree+0x220/0x2f0[ 57.566792] clk_summary_show_subtree+0x220/0x2f0[ 57.571450] clk_summary_show+0x84/0xb8[ 57.575245] seq_read_iter+0x1bc/0x4b8[ 57.578954] seq_read+0x8c/0xd0[ 57.582059] full_proxy_read+0x68/0xc8[ 57.585767] vfs_read+0xb0/0x268[ 57.588959] ksys_read+0x70/0x108[ 57.592236] __arm64_sys_read+0x24/0x38[ 57.596031] invoke_syscall+0x50/0x128[ 57.599740] el0_svc_common.constprop.0+0x48/0xf8[ 57.604397] do_el0_svc+0x28/0x40[ 57.607675] el0_svc+0x34/0xb8[ 57.610694] el0t_64_sync_handler+0x13c/0x158[ 57.615006] el0t_64_sync+0x190/0x198[ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)[ 57.624668] ---[ end trace 0000000000000000 ]---[jbrunet: add missing Fixes tag]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is received on HIP08 devicesThe HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL, but the hardware can receive 1588 messages,and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, theaccess of hdev->ptp->flags will cause a kernel crash:[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge][ 5889.279101] sp : ffff800012c3bc50[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080[ 5889.378857] Call trace:[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3][ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3][ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3][ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3][ 5889.411084] napi_poll+0xcc/0x264[ 5889.415329] net_rx_action+0xd4/0x21c[ 5889.419911] __do_softirq+0x130/0x358[ 5889.424484] irq_exit+0x134/0x154[ 5889.428700] __handle_domain_irq+0x88/0xf0[ 5889.433684] gic_handle_irq+0x78/0x2c0[ 5889.438319] el1_irq+0xb8/0x140[ 5889.442354] arch_cpu_idle+0x18/0x40[ 5889.446816] default_idle_call+0x5c/0x1c0[ 5889.451714] cpuidle_idle_call+0x174/0x1b0[ 5889.456692] do_idle+0xc8/0x160[ 5889.460717] cpu_startup_entry+0x30/0xfc[ 5889.465523] secondary_start_kernel+0x158/0x1ec[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)[ 5889.477950] SMP: stopping secondary CPUs[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95[ 5890.522951] Starting crashdump kernel...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()Apply the same fix than ones found in :8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.syzbot reported:BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix DEVMAP_HASH overflow check on 32-bit archesThe devmap code allocates a number hash buckets equal to the next powerof two of the max_entries value provided when creating the map. Whenrounding up to the next power of two, the 32-bit variable storing thenumber of buckets can overflow, and the code checks for overflow bychecking if the truncated 32-bit value is equal to 0. However, on 32-bitarches the rounding up itself can overflow mid-way through, because itends up doing a left-shift of 32 bits on an unsigned long value. If thesize of an unsigned long is four bytes, this is undefined behaviour, sothere is no guarantee that we'll end up with a nice and tidy 0-value atthe end.Syzbot managed to turn this into a crash on arm32 by creating aDEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.Fix this by moving the overflow check to before the rounding upoperation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26886 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: af_bluetooth: Fix deadlockAttemting to do sock_lock on .recvmsg may cause a deadlock as shownbellow, so instead of using sock_sock this uses sk_receive_queue.lockon bt_sock_ioctl to avoid the UAF:INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183Workqueue: hci0 hci_rx_workCall Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26894 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()After unregistering the CPU idle device, the memory associated withit is not freed, leading to a memory leak:unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50Fix this by freeing the CPU idle device after unregistering it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix memory leak when starting APKmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4However, since the kernel is build optimized, it seems the stack is notaccurate. It appears the issue is related to wfx_set_mfp_ap(). The issueis obvious in this function: memory allocated by ieee80211_beacon_get()is never released. Fixing this leak makes kmemleak happy.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix kmemleak of rdev->serialIf kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will bealloc not be freed, and kmemleak occurs.unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Reset IH OVERFLOW_CLEAR bitAllows us to detect subsequent IH ring buffer overflows as well.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: validate the parameters of bo mapping operations more clearlyVerify the parameters ofamdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface's parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected. As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete. But usb_deauthorize_interface() can't completeuntil the device lock has been released, and the lock won't bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun Reported by: xingwei lee

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: netlink: access device through ctx instead of peerThe previous commit fixed a bug that led to a NULL peer->device beingdereferenced. It's actually easier and faster performance-wise toinstead get the device from ctx->wg. This semantically makes more sensetoo, since ctx->wg->peer_allowedips.seq is compared withctx->allowedips_seq, basing them both in ctx. This also acts as adefence in depth provision against freed peers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: esp: fix bad handling of pages from page_poolWhen the skb is reorganized during esp_output (!esp->inline), the pagescoming from the original skb fragments are supposed to be released backto the system through put_page. But if the skb fragment pages areoriginating from a page_pool, calling put_page on them will trigger apage_pool leak which will eventually result in a crash.This leak can be easily observed when using CONFIG_DEBUG_VM and doingipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 gro_cell_poll+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 The suggested fix is to introduce a new wrapper (skb_page_unref) thatcovers page refcounting for page_pool pages as well.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: fix reference counting on zcrypt card objectsTests with hot-plugging crytpo cards on KVM guests with debugkernel build revealed an use after free for the load field ofthe struct zcrypt_card. The reason was an incorrect referencehandling of the zcrypt card object which could lead to a freeof the zcrypt card object while it was still in use.This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26960 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: fix race between free_swap_and_cache() and swapoff()There was previously a theoretical window where swapoff() could run andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread. This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_swap_and_cache()) to access the freed memory for swap_map.This is a theoretical problem and I haven't been able to provoke it from atest case. But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff(). There was an extra check in _swap_info_get() to confirm thatthe swap entry was not free. This isn't present in get_swap_device()because it doesn't make sense in general due to the race between gettingthe reference and swapoff. So I've added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor deriving this):--8<-----__swap_entry_free() might be the last user and result in"count == SWAP_HAS_CACHE".swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.So the question is: could someone reclaim the folio and turnsi->inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill references by swap entries.Process 1 still references subpage 0 via swap entry.Process 2 still references subpage 1 via swap entry.Process 1 quits. Calls free_swap_and_cache().-> count == SWAP_HAS_CACHE[then, preempted in the hypervisor etc.]Process 2 quits. Calls free_swap_and_cache().-> count == SWAP_HAS_CACHEProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls__try_to_reclaim_swap().__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->put_swap_folio()->free_swap_slot()->swapcache_free_entries()->swap_entry_free()->swap_range_free()->...WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);What stops swapoff to succeed after process 2 reclaimed the swap cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8<-----

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26962 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshapeFor raid456, if reshape is still in progress, then IO across reshapeposition will wait for reshape to make progress. However, for dm-raid,in following cases reshape will never make progress hence IO will hang:1) the array is read-only;2) MD_RECOVERY_WAIT is set;3) MD_RECOVERY_FROZEN is set;After commit c467e97f079f ("md/raid6: use valid sector values to determineif an I/O should wait on the reshape") fix the problem that IO acrossreshape position doesn't wait for reshape, the dm-raid testshell/lvconvert-raid-reshape.sh start to hang:[root@fedora ~]# cat /proc/979/stack[<0>] wait_woken+0x7d/0x90[<0>] raid5_make_request+0x929/0x1d70 [raid456][<0>] md_handle_request+0xc2/0x3b0 [md_mod][<0>] raid_map+0x2c/0x50 [dm_raid][<0>] __map_bio+0x251/0x380 [dm_mod][<0>] dm_submit_bio+0x1f0/0x760 [dm_mod][<0>] __submit_bio+0xc2/0x1c0[<0>] submit_bio_noacct_nocheck+0x17f/0x450[<0>] submit_bio_noacct+0x2bc/0x780[<0>] submit_bio+0x70/0xc0[<0>] mpage_readahead+0x169/0x1f0[<0>] blkdev_readahead+0x18/0x30[<0>] read_pages+0x7c/0x3b0[<0>] page_cache_ra_unbounded+0x1ab/0x280[<0>] force_page_cache_ra+0x9e/0x130[<0>] page_cache_sync_ra+0x3b/0x110[<0>] filemap_get_pages+0x143/0xa30[<0>] filemap_read+0xdc/0x4b0[<0>] blkdev_read_iter+0x75/0x200[<0>] vfs_read+0x272/0x460[<0>] ksys_read+0x7a/0x170[<0>] __x64_sys_read+0x1c/0x30[<0>] do_syscall_64+0xc6/0x230[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74This is because reshape can't make progress.For md/raid, the problem doesn't exist because register new sync_threaddoesn't rely on the IO to be done any more:1) If array is read-only, it can switch to read-write by ioctl/sysfs;2) md/raid never set MD_RECOVERY_WAIT;3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.However, I'm not sure yet how to avoid the problem in dm-raid yet. Thispatch on the one hand make sure raid_message() can't changesync_thread() through raid_message() after presuspend(), on the otherhand detect the above 3 cases before wait for IO do be done indm_suspend(), and let dm-raid requeue those IO.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-msm8974: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: gcc-ipq8074: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fat: fix uninitialized field in nostale filehandlesWhen fat_encode_fh_nostale() encodes file handle without a parent itstores only first 10 bytes of the file handle. However the length of thefile handle must be a multiple of 4 so the file handle is actually 12bytes long and the last two bytes remain uninitialized. This is notgreat at we potentially leak uninitialized information with the handleto userspace. Properly initialize the full handle length.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26974 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - resolve race condition during AER recoveryDuring the PCI AER system's error recovery process, the kernel drivermay encounter a race condition with freeing the reset_data structure'smemory. If the device restart will take more than 10 seconds the functionscheduling that restart will exit due to a timeout, and the reset_datastructure will be freed. However, this data structure is used forcompletion notification after the restart is completed, which leadsto a UAF bug.This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340To resolve this race condition, the memory associated to the containerof the work_struct is freed on the worker if the timeout expired,otherwise on the function that schedules the worker.The timeout detection can be done by checking if the caller isstill waiting for completion or not by using completion_done() function.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check the inode number is not the invalid value of zeroSyskiller has produced an out of bounds access in fill_meta_index().That out of bounds access is ultimately caused because the inodehas an inode number with the invalid value of zero, which was not checked.The reason this causes the out of bounds access is due to followingsequence of events:1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode numberis not zero when the inode is created and returns -EINVAL if it is.[phillip@squashfs.org.uk: whitespace fix]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: Do a runtime PM get on controllers during probemt8183-mfgcfg has a mutual dependency with genpd during the probingstage, which leads to a deadlock in the following call stack:CPU0: genpd_lock --> clk_prepare_lockgenpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()CPU1: clk_prepare_lock --> genpd_lockclk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()Do a runtime PM get at the probe function to make sure clk_register()won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,do this on all mediatek clock controller probings because we don'tbelieve this would cause any regression.Verified on MT8183 and MT8192 Chromebooks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix mirred deadlock on device recursionWhen the mirred action is used on a classful egress qdisc and a packet ismirrored or redirected to self we hit a qdisc lock deadlock.See trace below.[..... other info removed for brevity....][ 82.890906][ 82.890906] ============================================[ 82.890906] WARNING: possible recursive locking detected[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W[ 82.890906] --------------------------------------------[ 82.890906] ping/418 is trying to acquire lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] but task is already holding lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] other info that might help us debug this:[ 82.890906] Possible unsafe locking scenario:[ 82.890906][ 82.890906] CPU0[ 82.890906] ----[ 82.890906] lock(&sch->q.lock);[ 82.890906] lock(&sch->q.lock);[ 82.890906][ 82.890906] *** DEADLOCK ***[ 82.890906][..... other info removed for brevity....]Example setup (eth0->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0Another example(eth0->eth1->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1tc qdisc add dev eth1 root handle 1: htb default 30tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0We fix this by adding an owner field (CPU id) to struct Qdisc set afterroot qdisc is entered. When the softirq enters it a second time, if theqdisc owner is the same CPU, the packet is dropped to break the loop.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak in map from abort pathThe delete set command does not rely on the transaction object forelement removal, therefore, a combination of delete element + delete setfrom the abort path could result in restoring twice the refcount of themapping.Check for inactive element in the next generation for the delete elementcommand in the abort path, skip restoring state if next generation bithas been already cleared. This is similar to the activate logic usingthe set walk iterator.[ 6170.286929] ------------[ cut here ]------------[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287071] Modules linked in: [...][ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0[ 6170.287962] Call Trace:[ 6170.287967] [ 6170.287973] ? __warn+0x9f/0x1a0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.288104] ? handle_bug+0x3c/0x70[ 6170.288112] ? exc_invalid_op+0x17/0x40[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tun: limit printing rate when illegal packet received by tun devvhost_worker will call tun call backs to receive packets. If too manyillegal packets arrives, tun_do_read will keep dumping packet contents.When console is enabled, it will costs much more cpu time to dumppacket and soft lockup will be detected.net_ratelimit mechanism can be used to limit the dumping rate.PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS works are canceled using the `cancel_work_sync` function,which waits for the work to end if it has already started.However, while waiting for the work handler, the handler willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker's responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I------------------------------------------------------ethtool/386089 is trying to acquire lock:ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0but task is already holding lock:ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4eother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK ***3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]stack backtrace:CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: incorrect pppoe tuplepppoe traffic reaching ingress path does not match the flowtable entrybecause the pppoe header is expected to be at the network header offset.This bug causes a mismatch in the flow table lookup, so pppoe packetsenter the classical forwarding path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: validate pppoe headerEnsure there is sufficient room to access the protocol field of thePPPoe header. Validate it once before the flowtable lookup, then use ahelper function to access protocol field.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()nft_unregister_obj() can concurrent with __nft_obj_type_get(),and there is not any protection when iterate over nf_tables_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()nft_unregister_expr() can concurrent with __nft_expr_type_get(),and there is not any protection when iterate over nf_tables_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: Fix clk_core_get NULL dereferenceIt is possible for clk_core_get to dereference a NULL in the followingsequence:clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw()__clk_get_hw() can return NULL which is dereferenced by clk_core_get() athw->core.Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev basedclk_lookups") the check IS_ERR_OR_NULL() was performed which would havecaught the NULL.Reading the description of this function it talks about returning NULL butthat cannot be so at the moment.Update the function to check for hw before dereferencing it and return NULLif hw is NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULLbefore the call to dc_enable_dmub_notifications(), checkbeforehand to ensure there will not be a possible NULL-ptr-derefthere.Also, since commit 1e88eb1b2c25 ("drm/amd/display: DropCONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().Clean up by combining them all under one 'if'.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'The 'stream' pointer is used in dcn10_set_output_transfer_func() beforethe check if 'stream' is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: flower: handle acti_netdevs allocation failureThe kmalloc_array() in nfp_fl_lag_do_work() will return null, ifthe physical memory has run out. As a result, if we dereferencethe acti_netdevs, the null pointer dereference bugs will happen.This patch adds a check to judge whether allocation failure occurs.If it happens, the delayed work will be rescheduled and try again.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27054 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/dasd: fix double module refcount decrementOnce the discipline is associated with the device, deleting the devicetakes care of decrementing the module's refcount. Doing it manually onthis error path causes refcount to artificially decrease on each errorwhile it should just stay the same.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: ensure offloading TID queue existsThe resume code path assumes that the TX queue for the offloading TIDhas been configured. At resume time it then tries to sync the writepointer as it may have been updated by the firmware.In the unusual event that no packets have been send on TID 0, the queuewill not have been allocated and this causes a crash. Fix this byensuring the queue exist at suspend time.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau: lock the client object tree.It appears the client object tree has no locking unless I've missedsomething else. Fix races around adding/removing client objects,mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4562.099544] Call Trace:[ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90[ 4562.099583] ? exc_general_protection+0x246/0x4a0[ 4562.099593] ? asm_exc_general_protection+0x26/0x30[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau][ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau][ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau][ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm][ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau][ 4562.100356] __do_fault+0x32/0x150[ 4562.100362] do_fault+0x7c/0x560[ 4562.100369] __handle_mm_fault+0x800/0xc10[ 4562.100382] handle_mm_fault+0x17c/0x3e0[ 4562.100388] do_user_addr_fault+0x208/0x860[ 4562.100395] exc_page_fault+0x7f/0x200[ 4562.100402] asm_exc_page_fault+0x26/0x30[ 4562.100412] RIP: 0033:0x9b9870[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 4562.100446] [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27065 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not compare internal table flags on updatesRestore skipping transaction if table update does not modify flags.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Remove useless locks in usbtv_video_free()Remove locks calls in usbtv_video_free() becauseare useless and may led to a deadlock as reported here:https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000Also remove usbtv_stop() call since it will be called whenunregistering the device.Before 'c838530d230b' this issue would only be noticed if youdisconnect while streaming and now it is noticeable even whendisconnecting while not streaming.[hverkuil: fix minor spelling mistake in log message]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27076 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx: csc/scaler: fix v4l2_ctrl_handler memory leakFree the memory allocated in v4l2_ctrl_handler_init on release.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: fix some memleaks in tpg_allocIn tpg_alloc, resources should be deallocated in each and everyerror-handling paths, since they are allocated in for statements.Otherwise there would be memleaks because tpg_free is called only whentpg_alloc return 0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27388 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix some memleaks in gssx_dec_option_arrayThe creds and oa->data need to be freed in the error-handling paths aftertheir allocation. So this patch add these deallocations in thecorresponding paths.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27393 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: Add missing skb_mark_for_recycleNotice that skb_mark_for_recycle() is introduced later than fixes tag incommit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").It is believed that fixes tag were missing a call to page_pool_release_page()between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().Since v6.6 the call page_pool_release_page() were removed (incommit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch'net-page_pool-remove-page_pool_release_page'")).This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catchpage_pool memory leaks").

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27395 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix Use-After-Free in ovs_ct_exitSince kfree_rcu, which is called in the hlist_for_each_entry_rcu traversalof ovs_ct_limit_exit, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27396 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gtp: Fix Use-After-Free in gtp_dellinkSince call_rcu, which is called in the hlist_for_each_entry_rcu traversalof gtp_dellink, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27399 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeoutThere is a race condition between l2cap_chan_timeout() andl2cap_chan_del(). When we use l2cap_chan_del() to delete thechannel, the chan->conn will be set to null. But the conn couldbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().As a result the null pointer dereference bug will happen. TheKASAN report triggered by POC is shown below:[ 472.074580] ==================================================================[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7[ 472.075308][ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.075308] Workqueue: events l2cap_chan_timeout[ 472.075308] Call Trace:[ 472.075308] [ 472.075308] dump_stack_lvl+0x137/0x1a0[ 472.075308] print_report+0x101/0x250[ 472.075308] ? __virt_addr_valid+0x77/0x160[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_report+0x139/0x170[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_check_range+0x2c3/0x2e0[ 472.075308] mutex_lock+0x68/0xc0[ 472.075308] l2cap_chan_timeout+0x181/0x300[ 472.075308] process_one_work+0x5d2/0xe00[ 472.075308] worker_thread+0xe1d/0x1660[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] kthread+0x2b7/0x350[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork+0x4d/0x80[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork_asm+0x11/0x20[ 472.075308] [ 472.075308] ==================================================================[ 472.094860] Disabling lock debugging due to kernel taint[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158[ 472.096136] #PF: supervisor write access in kernel mode[ 472.096136] #PF: error_code(0x0002) - not-present page[ 472.096136] PGD 0 P4D 0[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.096136] Workqueue: events l2cap_chan_timeout[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0[ 472.096136] Call Trace:[ 472.096136] [ 472.096136] ? __die_body+0x8d/0xe0[ 472.096136] ? page_fault_oops+0x6b8/0x9a0[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0[ 472.096136] ? do_user_addr_fault+0x1027/0x1340[ 472.096136] ? _printk+0x7a/0xa0[ 472.096136] ? mutex_lock+0x68/0xc0[ 472.096136] ? add_taint+0x42/0xd0[ 472.096136] ? exc_page_fault+0x6a/0x1b0[ 472.096136] ? asm_exc_page_fault+0x26/0x30[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] ? mutex_lock+0x88/0xc0[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] l2cap_chan_timeo---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27403 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_flow_offload: reset dst in route object after setting up flowdst is transferred to the flow object, route object does not own itanymore. Reset dst in route object, otherwise if flow_offload_add()fails, error path releases dst twice, leading to a refcount underflow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27416 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUESTIf we received HCI_EV_IO_CAPA_REQUEST whileHCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remotedoes support SSP since otherwise this event shouldn't be generated.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27435 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix reconnection fail due to reserved tag allocationWe found a issue on production environment while using NVMe over RDMA,admin_q reconnect failed forever while remote target and network is ok.After dig into it, we found it may caused by a ABBA deadlock due to tagallocation. In my case, the tag was hold by a keep alive requestwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so therequest maked as idle and will not process before reset success. Asfabric_q shares tagset with admin_q, while reconnect remote target, weneed a tag for connect command, but the only one reserved tag was heldby keep alive command which waiting inside admin_q. As a result, wefailed to reconnect admin_q forever. In order to fix this issue, Ithink we should keep two reserved tags for admin queue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27436 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Stop parsing channels bits when all channels are found.If a usb audio device sets more bits than the amount of channelsit could write outside of the map array.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-33621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: region: add owner module and take its refcountThe current implementation of the fpga region assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the regionduring programming if the parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_regionstruct and use it to take the module's refcount. Modify the functions forregistering a region to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the region as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a region without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga region.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid: really frozen sync_thread during suspend1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes().2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used.3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend().4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), thetest shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),and with previous fixes, the test won't hang there anymore, however, thetest will still fail and complain that ext4 is corrupted. And with thispatch, the test won't hang due to stop_sync_thread() or fail due to ext4is corrupted anymore. However, there is still a deadlock related todm-raid456 that will be fixed in following patches.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ll_temac: platform_get_resource replaced by wrong functionThe function platform_get_resource was replaced withdevm_platform_ioremap_resource_byname and is called using 0 as name.This eventually ends up in platform_get_resource_byname in the callstack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name))It should have been replaced with devm_platform_ioremap_resource.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Keep xfd_state in sync with MSR_IA32_XFDCommit 672365477ae8 ("x86/fpu: Update XFD state where required") andcommit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced aper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, inorder to avoid unnecessary writes to the MSR.On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, whichwipes out any stale state. But the per CPU cached xfd value is notreset, which brings them out of sync.As a consequence a subsequent xfd_update_state() might fail to updatethe MSR which in turn can result in XRSTOR raising a #NM in kernelspace, which crashes the kernel.To fix this, introduce xfd_set_state() to write xfd_state togetherwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Mark target gfn of emulated atomic instruction as dirtyWhen emulating an atomic access on behalf of the guest, mark the targetgfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. Thisfixes a bug where KVM effectively corrupts guest memory during livemigration by writing to guest memory without informing userspace that thepage is dirty.Marking the page dirty got unintentionally dropped when KVM's emulatedCMPXCHG was converted to do a user access. Before that, KVM explicitlymapped the guest page into kernel memory, and marked the page dirty duringthe unmap phase.Mark the page dirty even if the CMPXCHG fails, as the old data is writtenback on failure, i.e. the page is still written. The value written isguaranteed to be the same because the operation is atomic, but KVM's ABIis that all writes are dirty logged regardless of the value written. Andmore importantly, that's what KVM did before the buggy commit.Huge kudos to the folks on the Cc list (and many others), who did all theactual work of triaging and debugging.base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm snapshot: fix lockup in dm_exception_table_exitThere was reported lockup when we exit a snapshot with many exceptions.Fix this by adding "cond_resched" to the loop that frees the exceptions.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix corruption during on-line resizeWe observed a corruption during on-line resize of a file system that islarger than 16 TiB with 4k block size. With having more then 2^32 blocksresize_inode is turned off by default by mke2fs. The issue can bereproduced on a smaller file system for convenience by explicitlyturning off resize_inode. An on-line resize across an 8 GiB boundary (thesize of a meta block group in this setup) then leads to a corruption: dev=/dev/ # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks perblock group and 2^6 are the number of block groups that make a metablock group.The last checksum might be different depending on how the file is laidout across the physical blocks. The actual corruption occurs at physicalblock 63*2^15 = 2064384 which would be the location of the backup of themeta block group's block descriptor. During the on-line resize the filesystem will be converted to meta_bg starting at s_first_meta_bg which is2 in the example - meaning all block groups after 16 GiB. However, inext4_flex_group_add we might add block groups that are not part of thefirst meta block group yet. In the reproducer we achieved this bysubstracting the size of a whole block group from the point where themeta block group would start. This must be considered when updating thebackup block group descriptors to follow the non-meta_bg layout. The fixis to add a test whether the group to add is already part of the metablock group or not.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/dm-raid: don't call md_reap_sync_thread() directlyCurrently md_reap_sync_thread() is called from raid_message() directlywithout holding 'reconfig_mutex', this is definitely unsafe becausemd_reap_sync_thread() can change many fields that is protected by'reconfig_mutex'.However, hold 'reconfig_mutex' here is still problematic because thiswill cause deadlock, for example, commit 130443d60b1b ("md: refactoridle/frozen_sync_thread() to fix deadlock").Fix this problem by using stop_sync_thread() to unregister sync_thread,like md/raid did.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: Set page uptodate in the correct placePage cache reads are lockless, so setting the freshly allocated pageuptodate before we've overwritten it with the data it's supposed to havein it will allow a simultaneous reader to see old data. Move the callto SetPageUptodate into ubifs_write_end(), which is after we copied thenew data into the page.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vt: fix unicode buffer corruption when deleting charactersThis is the same issue that was fixed for the VGA text buffer in commit39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in thebuffer"). The cure is also the same i.e. replace memcpy() with memmove()due to the overlaping buffers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: ncm: Fix handling of zero block length packetsWhile connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TXset to 65536, it has been observed that we receive short packets,which come at interval of 5-10 seconds sometimes and have blocklength zero but still contain 1-2 valid datagrams present.According to the NCM spec:"If wBlockLength = 0x0000, the block is terminated by ashort packet. In this case, the USB transfer must stillbe shorter than dwNtbInMaxSize or dwNtbOutMaxSize. Ifexactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,and the size is a multiple of wMaxPacketSize for thegiven pipe, then no ZLP shall be sent.wBlockLength= 0x0000 must be used with extreme care, becauseof the possibility that the host and device may get out ofsync, and because of test issues.wBlockLength = 0x0000 allows the sender to reduce latency bystarting to send a very large NTB, and then shortening it whenthe sender discovers that there's not sufficient data to justifysending a large NTB"However, there is a potential issue with the current implementation,as it checks for the occurrence of multiple NTBs in a singlegiveback by verifying if the leftover bytes to be processed is zeroor not. If the block length reads zero, we would process the sameNTB infintely because the leftover bytes is never zero and it leadsto a crash. Fix this by bailing out if block length reads zero.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/lima: fix a memleak in lima_heap_allocWhen lima_vm_map_bo fails, the resources need to be deallocated, orthere will be memleaks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: tc358743: register v4l2 async device only after successful setupEnsure the device has been setup correctly before registering the v4l2async device, thus allowing userspace to access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMAThis dma_alloc_coherent() is undone neither in the remove function, nor inthe error handling path of fsl_qdma_probe().Switch to the managed version to fix both issues.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35837 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: clear BM pool before initializationRegister value persist after booting the kernel usingkexec which results in kernel panic. Thus clear theBM pool registers before initialisation to fix the issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35845 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: dbg-tlv: ensure NUL terminationThe iwl_fw_ini_debug_info_tlv is used as a string, so we mustensure the string is terminated correctly before using it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Prevent double free on errorThe error handling path in its_vpe_irq_domain_alloc() causes a double freewhen its_vpe_init() fails after successfully allocating at least oneinterrupt. This happens because its_vpe_irq_domain_free() frees theinterrupts along with the area bitmap and the vprop_page andits_vpe_irq_domain_alloc() subsequently frees the area bitmap and thevprop_page again.Fix this by unconditionally invoking its_vpe_irq_domain_free() whichhandles all cases correctly and by removing the bitmap/vprop_page freeingfrom its_vpe_irq_domain_alloc().[ tglx: Massaged change log ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:eeprom: at24: fix memory corruption race conditionIf the eeprom is not accessible, an nvmem device will be registered, theread will fail, and the device will be torn down. If another driveraccesses the nvmem device after the teardown, it will referenceinvalid memory.Move the failure point before registering the nvmem device.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35849 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix information leak in btrfs_ioctl_logical_to_ino()Syzbot reported the following information leak for inbtrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000This happens, because we're copying a 'struct btrfs_data_container' backto user-space. This btrfs_data_container is allocated in'init_data_container()' via kvmalloc(), which does not zero-fill thememory.Fix this by using kvzalloc() which zeroes out the memory on allocation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: qca: fix NULL-deref on non-serdev suspendQualcomm ROME controllers can be registered from the Bluetooth linediscipline and in this case the HCI UART serdev pointer is NULL.Add the missing sanity check to prevent a NULL-pointer dereference whenwakeup() is called for a non-serdev controller during suspend.Just return true for now to restore the original behaviour and addressthe crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657("Bluetooth: hci_qca: only assign wakeup with serial port support") thatcauses the crash to happen already at setup() time.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash workThe rehash delayed work is rescheduled with a delay if the number ofcredits at end of the work is not negative as supposedly it means thatthe migration ended. Otherwise, it is rescheduled immediately.After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free duringrehash" the above is no longer accurate as a non-negative number ofcredits is no longer indicative of the migration being done. It can alsohappen if the work encountered an error in which case the migration willresume the next time the work is scheduled.The significance of the above is that it is possible for the work to bepending and associated with hints that were allocated when the migrationstarted. This leads to the hints being leaked [1] when the work iscanceled while pending as part of ACL region dismantle.Fix by freeing the hints if hints are associated with a work that wascanceled while pending.Blame the original commit since the reliance on not having a pendingwork associated with hints is fragile.[1]unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak during rehashThe rehash delayed work migrates filters from one region to another.This is done by iterating over all chunks (all the filters with the samepriority) in the region and in each chunk iterating over all thefilters.If the migration fails, the code tries to migrate the filters back tothe old region. However, the rollback itself can also fail in which caseanother migration will be erroneously performed. Besides the fact thatthis ping pong is not a very good idea, it also creates a problem.Each virtual chunk references two chunks: The currently used one('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration thefirst holds the chunk we want to migrate filters to and the second holdsthe chunk we are migrating filters from.The code currently assumes - but does not verify - that the backup chunkdoes not exist (NULL) if the currently used chunk does not reference thetarget region. This assumption breaks when we are trying to rollback arollback, resulting in the backup chunk being overwritten and leaked[1].Fix by not rolling back a failed rollback and add a warning to avoidfuture cases.[1]WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20Modules linked in:CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:parman_destroy+0x17/0x20[...]Call Trace: mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35854 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehashThe rehash delayed work migrates filters from one region to anotheraccording to the number of available credits.The migrated from region is destroyed at the end of the work if thenumber of credits is non-negative as the assumption is that this isindicative of migration being complete. This assumption is incorrect asa non-negative number of credits can also be the result of a failedmigration.The destruction of a region that still has filters referencing it canresult in a use-after-free [1].Fix by not destroying the region if migration failed.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workCall Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity updateThe rule activity update delayed work periodically traverses the list ofconfigured rules and queries their activity from the device.As part of this task it accesses the entry pointed by 'ventry->entry',but this entry can be changed concurrently by the rehash delayed work,leading to a use-after-free [1].Fix by closing the race and perform the activity query under the'vregion->lock' mutex.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_workCall Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: prevent possible NULL dereferences from icmp_build_probe()First problem is a double call to __in_dev_get_rcu(), becausethe second one could return NULL.if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)Second problem is a read from dev->ip6_ptr with no NULL check:if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))Use the correct RCU API to fix these.v2: add missing include

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in cifs_dump_full_key()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in smb2_reconnect_server()The UAF bug is due to smb2_reconnect_server() accessing a session thatis already being teared down by another thread that is executing__cifs_put_smb_ses(). This can happen when (a) the client hasconnection to the server but no session or (b) another thread ends upsetting @ses->ses_status again to something different thanSES_EXITING.To fix this, we need to make sure to unconditionally set@ses->ses_status to SES_EXITING and prevent any other threads fromsetting a new status while we're still tearing it down.The following can be reproduced by adding some delay to right afterthe ipc is freed in __cifs_put_smb_ses() - which will givesmb2_reconnect_server() worker a chance to run and then accessing@ses->ipc:kinit ...mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10[disconnect srv]ls /mnt/1 &>/dev/nullsleep 30kdestroy[reconnect srv]sleep 10umount /mnt/1...CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126general protection fault, probably for non-canonical address0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc3904/01/2014Workqueue: cifsiod smb2_reconnect_server [cifs]RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 adde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 757b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6bRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000FS: 0000000000000000(0000) GS:ffff888157c00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix GUP-fast succeeding on secretmem foliosfolio_is_secretmem() currently relies on secretmem folios being LRUfolios, to save some cycles.However, folios might reside in a folio batch without the LRU flag set, ortemporarily have their LRU flag cleared. Consequently, the LRU flag isunreliable for this purpose.In particular, this is the case when secretmem_fault() allocates a freshpage and calls filemap_add_folio()->folio_add_lru(). The folio might beadded to the per-cpu folio batch and won't get the LRU flag set until thebatch was drained using e.g., lru_add_drain().Consequently, folio_is_secretmem() might not detect secretmem folios andGUP-fast can succeed in grabbing a secretmem folio, crashing the kernelwhen we would later try reading/writing to the folio, because the foliohas been unmapped from the directmap.Fix it by removing that unreliable check.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: fix VM_PAT handling in COW mappingsPAT handling won't do the right thing in COW mappings: the first PTE (or,in fact, all PTEs) can be replaced during write faults to point at anonfolios. Reliably recovering the correct PFN and cachemode usingfollow_phys() from PTEs will not work in COW mappings.Using follow_phys(), we might just get the address+protection of the anonfolio (which is very wrong), or fail on swap/nonswap entries, failingfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() andtrack_pfn_copy(), not properly calling free_pfn_range().In free_pfn_range(), we either wouldn't call memtype_free() or would callit with the wrong range, possibly leaking memory.To fix that, let's update follow_phys() to refuse returning anon folios,and fallback to using the stored PFN inside vma->vm_pgoff for COW mappingsif we run into that.We will now properly handle untrack_pfn() with COW mappings, where wedon't need the cachemode. We'll have to fail fork()->track_pfn_copy() ifthe first page was replaced by an anon folio, though: we'd have to storethe cachemode in the VMA to make this work, likely growing the VMA size.For now, lets keep it simple and let track_pfn_copy() just fail in thatcase: it would have failed in the past with swap/nonswap entries already,and it would have done the wrong thing with anon folios.Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():<--- C reproducer ---> #include #include #include #include int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; }<--- C reproducer --->On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring[ 301.552930] ------------[ cut here ]------------[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0[ 301.565725] PKRU: 55555554[ 301.565944] Call Trace:[ 301.566148] [ 301.566325] ? untrack_pfn+0xf4/0x100[ 301.566618] ? __warn+0x81/0x130[ 301.566876] ? untrack_pfn+0xf4/0x100[ 3---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: dynamic: Synchronize of_changeset_destroy() with the devlink removalsIn the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove()During the step 1, devices are destroyed and devlinks are removed.During the step 2, OF nodes are destroyed but__of_changeset_entry_destroy() can raise warnings related to missingof_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ...Indeed, during the devlink removals performed at step 1, the removalitself releasing the device (and the attached of_node) is done by a jobqueued in a workqueue and so, it is done asynchronously with respect tofunction calls.When the warning is present, of_node_put() will be called but wronglytoo late from the workqueue job.In order to be sure that any ongoing devlink removals are done beforethe of_node destruction, synchronize the of_changeset_destroy() with thedevlink removals.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp: do not accept non-tunnel GSO skbs landing in a tunnelWhen rx-udp-gro-forwarding is enabled UDP packets might be GROed whenbeing forwarded. If such packets might land in a tunnel this can causevarious issues and udp_gro_receive makes sure this isn't the case bylooking for a matching socket. This is performed inudp4/6_gro_lookup_skb but only in the current netns. This is an issuewith tunneled packets when the endpoint is in another netns. In suchcases the packets will be GROed at the UDP level, which leads to variousissues later on. The same thing can happen with rx-gro-list.We saw this with geneve packets being GROed at the UDP level. In suchcase gso_size is set; later the packet goes through the geneve rx path,the geneve header is pulled, the offset are adjusted and frag_list skbsare not adjusted with regard to geneve. When those skbs hitskb_fragment, it will misbehave. Different outcomes are possibledepending on what the GROed skbs look like; from corrupted packets tokernel crashes.One example is a BUG_ON[1] triggered in skb_segment while processing thefrag_list. Because gso_size is wrong (geneve header was pulled)skb_segment thinks there is "geneve header size" of data in frag_list,although it's in fact the next packet. The BUG_ON itself has nothing todo with the issue. This is only one of the potential issues.Looking up for a matching socket in udp_gro_receive is fragile: thelookup could be extended to all netns (not speaking about performances)but nothing prevents those packets from being modified in between and wecould still not find a matching socket. It's OK to keep the currentlogic there as it should cover most cases but we also need to make surewe handle tunnel packets being GROed too early.This is done by extending the checks in udp_unexpected_gso: GSO packetslacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel mustbe segmented.[1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxbf_gige: stop interface during shutdownThe mlxbf_gige driver intermittantly encounters a NULL pointerexception while the system is shutting down via "reboot" command.The mlxbf_driver will experience an exception right after executingits shutdown() method. One example of this exception is:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000[0000000000000070] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] SMPCPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]sp : ffff8000080d3c10x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffffx17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)---[ end trace 7cc3941aa0d8e6a4 ]---Kernel panic - not syncing: Oops: Fatal exception in interruptKernel Offset: 0x4ce722520000 from 0xffff800008000000PHYS_OFFSET: 0x80000000CPU features: 0x000005c1,a3330e5aMemory Limit: none---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---During system shutdown, the mlxbf_gige driver's shutdown() is always executed.However, the driver's stop() method will only execute if networking interfaceconfiguration logic within the Linux distribution has been setup to do so.If shutdown() executes but stop() does not execute, NAPI remains enabledand this can lead to an exception if NAPI is scheduled while the hardwareinterface has only been partially deinitialized.The networking interface managed by the mlxbf_gige driver must be properlystopped during system shutdown so that IFF_UP is cleared, the hardwareinterface is put into a clean state, and NAPI is fully deinitialized.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35887 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix use-after-free bugs caused by ax25_ds_del_timerWhen the ax25 device is detaching, the ax25_dev_device_down()calls ax25_ds_del_timer() to cleanup the slave_timer. Whenthe timer handler is running, the ax25_ds_del_timer() thatcalls del_timer() in it will return directly. As a result,the use-after-free bugs could happen, one of the scenariosis shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout()ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USEIn order to mitigate bugs, when the device is detaching, usetimer_shutdown_sync() to stop the timer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: make sure erspan_base_hdr is present in skb->headsyzbot reported a problem in ip6erspan_rcv() [1]Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer makesure erspan_base_hdr is present in skb linear part (skb->head)before getting @ver field from it.Add the missing pskb_may_pull() calls.v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed.[1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35893 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbmod: prevent kernel-infoleaksyzbot found that tcf_skbmod_dump() was copying four bytesfrom kernel stack to user space [1].The issue here is that 'struct tc_skbmod' has a four bytes hole.We need to clear the structure before filling fields.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35897 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: discard table flag update with pending basechain deletionHook unregistration is deferred to the commit phase, same occurs withhook updates triggered by the table dormant flag. When both commands arecombined, this results in deleting a basechain while leaving its hookstill registered in the core.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()nft_unregister_flowtable_type() within nf_flow_inet_module_exit() canconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().And thhere is not any protection when iterate over nf_tables_flowtableslist in __nft_flowtable_type_get(). Therefore, there is pertentialdata-race of nf_tables_flowtables list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables listin __nft_flowtable_type_get(), and use rcu_read_lock() in the callernft_flowtable_type_get() to protect the entire type query process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: flush pending destroy work before exit_net releaseSimilar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroywork before netlink notifier") to address a race between exit_net andthe destroy workqueue.The trace below shows an element to be released via destroy workqueuewhile exit_net path (triggered via module removal) has already releasedthe set that is used in such transaction.[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables][ 1360.547984] Call Trace:[ 1360.547991] [ 1360.547998] dump_stack_lvl+0x53/0x70[ 1360.548014] print_report+0xc4/0x610[ 1360.548026] ? __virt_addr_valid+0xba/0x160[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548176] kasan_report+0xae/0xe0[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables][ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30[ 1360.548591] process_one_work+0x2f1/0x670[ 1360.548610] worker_thread+0x4d3/0x760[ 1360.548627] ? __pfx_worker_thread+0x10/0x10[ 1360.548640] kthread+0x16b/0x1b0[ 1360.548653] ? __pfx_kthread+0x10/0x10[ 1360.548665] ret_from_fork+0x2f/0x50[ 1360.548679] ? __pfx_kthread+0x10/0x10[ 1360.548690] ret_from_fork_asm+0x1a/0x30[ 1360.548707] [ 1360.548719] Allocated by task 192061:[ 1360.548726] kasan_save_stack+0x20/0x40[ 1360.548739] kasan_save_track+0x14/0x30[ 1360.548750] __kasan_kmalloc+0x8f/0xa0[ 1360.548760] __kmalloc_node+0x1f1/0x450[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables][ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink][ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink][ 1360.548927] netlink_unicast+0x367/0x4f0[ 1360.548935] netlink_sendmsg+0x34b/0x610[ 1360.548944] ____sys_sendmsg+0x4d4/0x510[ 1360.548953] ___sys_sendmsg+0xc9/0x120[ 1360.548961] __sys_sendmsg+0xbe/0x140[ 1360.548971] do_syscall_64+0x55/0x120[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 1360.548994] Freed by task 192222:[ 1360.548999] kasan_save_stack+0x20/0x40[ 1360.549009] kasan_save_track+0x14/0x30[ 1360.549019] kasan_save_free_info+0x3b/0x60[ 1360.549028] poison_slab_object+0x100/0x180[ 1360.549036] __kasan_slab_free+0x14/0x30[ 1360.549042] kfree+0xb6/0x260[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables][ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables][ 1360.549221] ops_exit_list+0x50/0xa0[ 1360.549229] free_exit_list+0x101/0x140[ 1360.549236] unregister_pernet_operations+0x107/0x160[ 1360.549245] unregister_pernet_subsys+0x1c/0x30[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables][ 1360.549345] __do_sys_delete_module+0x253/0x370[ 1360.549352] do_syscall_64+0x55/0x120[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d(gdb) list *__nft_release_table+0x4730x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {11350 list_del(&flowtable->list);11351 nft_use_dec(&table->use);11352 nf_tables_flowtable_destroy(flowtable);11353 }11354 list_for_each_entry_safe(set, ns, &table->sets, list) {11355 list_del(&set->list);11356 nft_use_dec(&table->use);11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))11358 nft_map_deactivat---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject new basechain after table flag updateWhen dormant flag is toggled, hooks are disabled in the commit phase byiterating over current chains in table (existing and new).The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; }which triggers the following warning when trying to unregister chain wwhich is already unregistered.[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260[...][ 127.322519] Call Trace:[ 127.322521] [ 127.322524] ? __warn+0x9f/0x1a0[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260[ 127.322537] ? report_bug+0x1b1/0x1e0[ 127.322545] ? handle_bug+0x3c/0x70[ 127.322552] ? exc_invalid_op+0x17/0x40[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20[ 127.322563] ? kasan_save_free_info+0x3b/0x60[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables][ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables][ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxbf_gige: call request_irq() after NAPI initializedThe mlxbf_gige driver encounters a NULL pointer exception inmlxbf_gige_open() when kdump is enabled. The sequence to reproducethe exception is as follows:a) enable kdumpb) trigger kdump via "echo c > /proc/sysrq-trigger"c) kdump kernel executesd) kdump kernel loads mlxbf_gige modulee) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought upf) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac el0_svc+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---The exception happens because there is a pending RX interrupt before thecall to request_irq(RX IRQ) executes. Then, the RX IRQ handler firesimmediately after this request_irq() completes. The---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35910 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe corresponding netns has been dismantled.Fortunately Josef Bacik could trigger the issue more often,and could test a patch I wrote two years ago.When TCP sockets are closed, we call inet_csk_clear_xmit_timers()to 'stop' the timers.inet_csk_clear_xmit_timers() can be called from any context,including when socket lock is held.This is the reason it uses sk_stop_timer(), aka del_timer().This means that ongoing timers might finish much later.For user sockets, this is fine because each running timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare terminated before the kernel socket is released.Modules using kernel sockets close them in their netns exit()handler.Also add sock_not_owned_by_me() helper to get LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e ("net: rds: acquire refcount on TCP sockets")which attempted to solve the issue in rds only.(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)We probably can remove the check_net() tests fromtcp_out_of_resources() and __tcp_close() in the future.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packetsyzbot reported the following uninit-value access issue [1][2]:nci_rx_work() parses and processes received packet. When the payloadlength is zero, each message type handler reads uninitialized payloadand KMSAN detects this issue. The receipt of a packet with a zero-sizepayload is considered unexpected, and therefore, such packets should besilently discarded.This patch resolved this issue by checking payload size before callingeach message type handler codes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbmon: prevent division by zero in fb_videomode_from_videomode()The expression htotal * vtotal can have a zero value onoverflow. It is necessary to prevent division by zero like infb_var_to_videomode().Found by Linux Verification Center (linuxtesting.org) with Svace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip do PCI error slot reset during RAS recoveryWhy: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35936 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,as it could be caused only by two impossible conditions:- at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1- after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35951 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()If some the pages or sgt allocation failed, we shouldn't release thepages ref we got earlier, otherwise we will end up with unbalancedget/put_pages() calls. We should instead leave everything in placeand let the BO release function deal with extra cleanup when the objectis destroyed, or let the fault handler try again next time it's called.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ast: Fix soft lockupThere is a while-loop in ast_dp_set_on_off() that could lead toinfinite-loop. This is because the register, VGACRI-Dx, checked inthis API is a scratch register actually controlled by a MCU, namedDPMCU, in BMC.These scratch registers are protected by scu-lock. If suc-lock is notoff, DPMCU can not update these registers and then host will have softlockup due to never updated status.DPMCU is used to control DP and relative registers to handshake withhost's VGA driver. Even the most time-consuming task, DP's linktraining, is less than 100ms. 200ms should be enough.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35955 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: Fix possible use-after-free issue on kprobe registrationWhen unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will takea time. `is_module_text_address()` and `__module_text_address()`works with MODULE_STATE_LIVE and MODULE_STATE_GOING.If we use `is_module_text_address()` and `__module_text_address()`separately, there is a chance that the first one is succeeded but thenext one is failed because module->state becomes MODULE_STATE_UNFORMEDbetween those operations.In `check_kprobe_address_safe()`, if the second `__module_text_address()`is failed, that is ignored because it expected a kernel_text address.But it may have failed simply because module->state has been changedto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modifynon-exist module text address (use-after-free).To fix this problem, we should not use separated `is_module_text_address()`and `__module_text_address()`, but use only `__module_text_address()`once and do `try_module_get(module)` which is only available withMODULE_STATE_LIVE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix not validating setsockopt user inputCheck user input length before copying data.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35966 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: Fix not validating setsockopt user inputsyzbot reported rfcomm_sock_setsockopt_old() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_oldnet/bluetooth/rfcomm/sock.c:632 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70net/bluetooth/rfcomm/sock.c:673Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix not validating setsockopt user inputsyzbot reported sco_sock_setsockopt() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90net/bluetooth/sco.c:893Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: fix header validation in geneve[6]_xmit_skbsyzbot is able to trigger an uninit-value in geneve_xmit() [1]Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())uses skb_protocol(skb, true), pskb_inet_may_pull() is only usingskb->protocol.If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,pskb_inet_may_pull() does nothing at all.If a vlan tag was provided by the caller (af_packet in the syzbot case),the network header might not point to the correct location, and skblinear part could be smaller than expected.Add skb_vlan_inet_prepare() to perform a complete mac validation.Use this in geneve for the moment, I suspect we need to adopt thismore broadly.v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types.v2,v3 - Addressed Sabrina comments on v1 and v2[1]BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35976 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RINGsyzbot reported an illegal copy in xsk_setsockopt() [1]Make sure to validate setsockopt() @optlen parameter.[1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75RIP: 0033:0x7fb40587de69Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)The buggy address belongs to the physical page:page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6canon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)page_type: 0xffffffff()raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as allocatedpage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c:---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In 'hci_req_sync_complete()', always free the previous syncrequest state before assigning reference to a new one.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:raid1: fix use-after-free for original bio in raid1_write_request()r1_bio->bios[] is used to record new bios that will be issued tounderlying disks, however, in raid1_write_request(), r1_bio->bios[]will set to the original bio temporarily. Meanwhile, if blocked rdevis set, free_r1bio() will be called causing that all r1_bio->bios[]to be freed:raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL for (i = 0; i < disks; i++) -> for each rdev in conf // first rdev is normal r1_bio->bios[0] = bio; -> set to original bio // second rdev is blocked if (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> original bio is freedTest scripts:mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-cleanfio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ -iodepth=128 -name=test -direct=1echo blocked > /sys/block/md0/md/rd2/stateTest result:BUG bio-264 (Not tainted): Object already free-----------------------------------------------------------------------------Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e/0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 entry_SYSCALL_64_after_hwframe+0x6c/0x74Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_request+0xadf/0x1150 md_handle_request+0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0Since that bios for underlying disks are not allocated yet, fix thisproblem by using mempool_free() directly to free the r1_bio.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon top of batman-adv. In this case, at least 116 byte would be needed.There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)in the log but the function will never finish. Problem here is that thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.While this should be handled proactively when:* interface with too low MTU is added* VLAN is added* non-purgeable local mac is added* MTU of an attached interface is reduced* fragmentation setting gets disabled (which most likely requires dropping attached interfaces)not all of these scenarios can be prevented because batman-adv is onlyconsuming events without the the possibility to prevent these actions(non-purgable MAC address added, MTU of an attached interface is reduced).It is therefore necessary to also make sure that the code is able to handlealso the situations when there were already incompatible systemconfiguration are present.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: smbus: fix NULL function pointer dereferenceBaruch reported an OOPS when using the designware controller as targetonly. Target-only modes break the assumption of one transfer functionalways being available. Fix this by always checking the pointer in__i2c_transfer.[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix oops during rmmod on single-CPU platformsDuring the removal of the idxd driver, registered offline callback isinvoked as part of the clean up process. However, on systems with onlyone CPU online, no valid target is available to migrate theperf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Fix the issue by preventing the migration of the perf context to aninvalid target.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma: xilinx_dpdma: Fix lockingThere are several places where either chan->lock or chan->vchan.lock wasnot held. Add appropriate locking. This fixes lockdep warnings like[ 31.077578] ------------[ cut here ]------------[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.077953] Modules linked in:[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98[ 31.078102] Hardware name: xlnx,zynqmp (DT)[ 31.078169] Workqueue: events_unbound deferred_probe_work_func[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0[ 31.078550] sp : ffffffc083bb2e10[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000[ 31.080307] Call trace:[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0[ 31.081139] commit_tail+0x234/0x294[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210[ 31.081363] drm_atomic_commit+0x100/0x140[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c[ 31.081725] drm_client_modeset_commit+0x34/0x5c[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168[ 31.081899] drm_fb_helper_set_par+0x50/0x70[ 31.081971] fbcon_init+0x538/0xc48[ 31.082047] visual_init+0x16c/0x23c[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634[ 31.082320] do_take_over_console+0x24c/0x33c[ 31.082429] do_fbcon_takeover+0xbc/0x1b0[ 31.082503] fbcon_fb_registered+0x2d0/0x34c[ 31.082663] register_framebuffer+0x27c/0x38c[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c[ 31.082939] drm_fb_helper_initial_config+0x50/0x74[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108[ 31.083115] drm_client_register+0xa0/0xf4[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0[ 31.083616] platform_probe+0x8c/0x13c[ 31.083713] really_probe+0x258/0x59c[ 31.083793] __driver_probe_device+0xc4/0x224[ 31.083878] driver_probe_device+0x70/0x1c0[ 31.083961] __device_attach_driver+0x108/0x1e0[ 31.084052] bus_for_each_drv+0x9c/0x100[ 31.084125] __device_attach+0x100/0x298[ 31.084207] device_initial_probe+0x14/0x20[ 31.084292] bus_probe_device+0xd8/0xdc[ 31.084368] deferred_probe_work_func+0x11c/0x180[ 31.084451] process_one_work+0x3ac/0x988[ 31.084643] worker_thread+0x398/0x694[ 31.084752] kthread+0x1bc/0x1c0[ 31.084848] ret_from_fork+0x10/0x20[ 31.084932] irq event stamp: 64549[ 31.084970] hardirqs last enabled at (64548): [] _raw_spin_unlock_irqrestore+0x80/0x90[ 31.085157]---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix missing hugetlb_lock for resv unchargeThere is a recent report on UFFDIO_COPY over hugetlb:https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/350: lockdep_assert_held(&hugetlb_lock);Should be an issue in hugetlb but triggered in an userfault context, whereit goes into the unlikely path where two threads modifying the resv maptogether. Mike has a fix in that path for resv uncharge but it looks likethe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()will update the cgroup pointer, so it requires to be called with the lockheld.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36004 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not use WQ_MEM_RECLAIM flag for workqueueIssue reported by customer during SRIOV testing, call trace:When both i40e and the i40iw driver are loaded, a warningin check_flush_dependency is being triggered. This seemsto be because of the i40e driver workqueue is allocated withthe WQ_MEM_RECLAIM flag, and the i40iw one is not.Similar error was encountered on ice too and it was fixed byremoving the flag. Do the same for i40e too.[Feb 9 09:08] ------------[ cut here ]------------[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] isflushing !WQ_MEM_RECLAIM infiniband:0x0[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966check_flush_dependency+0x10b/0x120[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seqsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtrrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdmaintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssifisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermalintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_coreiTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncoreioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ichintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_padxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbedrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intellibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirrordm_region_hash dm_log dm_mod fuse[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Nottainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOSSE5C620.86B.02.01.0013.121520200651 12/15/2020[ +0.000001] Workqueue: i40e i40e_service_task [i40e][ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 4881 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fdff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:0000000000000027[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:ffff94d47f620bc0[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:00000000ffff7fff[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:ffff94c5451ea180[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:ffff94c5f1330ab0[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)knlGS:0000000000000000[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:00000000007706f0[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[ +0.000001] PKRU: 55555554[ +0.000001] Call Trace:[ +0.000001] [ +0.000002] ? __warn+0x80/0x130[ +0.000003] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? report_bug+0x195/0x1a0[ +0.000005] ? handle_bug+0x3c/0x70[ +0.000003] ? exc_invalid_op+0x14/0x70[ +0.000002] ? asm_exc_invalid_op+0x16/0x20[ +0.000006] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? check_flush_dependency+0x10b/0x120[ +0.000002] __flush_workqueue+0x126/0x3f0[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core][ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core][ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core][ +0.000020] i40iw_close+0x4b/0x90 [irdma][ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e][ +0.000035] i40e_service_task+0x126/0x190 [i40e][ +0.000024] process_one_work+0x174/0x340[ +0.000003] worker_th---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: honor table dormant flag from netdev release event pathCheck for table dormant flag otherwise netdev release event path triesto unregister an already unregistered hook.[524854.857999] ------------[ cut here ]------------[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260[...][524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365[524854.858869] Workqueue: netns cleanup_net[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0[524854.859000] Call Trace:[524854.859006] [524854.859013] ? __warn+0x9f/0x1a0[524854.859027] ? __nf_unregister_net_hook+0x21a/0x260[524854.859044] ? report_bug+0x1b1/0x1e0[524854.859060] ? handle_bug+0x3c/0x70[524854.859071] ? exc_invalid_op+0x17/0x40[524854.859083] ? asm_exc_invalid_op+0x1a/0x20[524854.859100] ? __nf_unregister_net_hook+0x6a/0x260[524854.859116] ? __nf_unregister_net_hook+0x21a/0x260[524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables][524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859461] ? packet_notifier+0xb3/0x360[524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40[524854.859489] ? dcbnl_netdevice_event+0x35/0x140[524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859661] notifier_call_chain+0x7d/0x140[524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()Extend a critical section to prevent chan from early freeing.Also make the l2cap_connect() return type void. Nothing is using thereturned value but it is ugly to return a potentially freed pointer.Making it void will help with backports because earlier kernels did usethe return value. Now the compile will break for kernels where thispatch is not a complete fix.Call stack summary:[use]l2cap_bredr_sig_cmd l2cap_connect mutex_lock(&conn->chan_lock); | chan = pchan->ops->new_connection(pchan); <- alloc chan | __l2cap_chan_add(conn, chan); | l2cap_chan_hold(chan); | list_add(&chan->list, &conn->chan_l); ... (1) mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free[free]l2cap_conn_del mutex_lock(&conn->chan_lock);| foreach chan in conn->chan_l: ... (2)| l2cap_chan_put(chan);| l2cap_chan_destroy| kfree(chan) ... (3) <- chan freed mutex_unlock(&conn->chan_lock);==================================================================BUG: KASAN: slab-use-after-free in instrument_atomic_readinclude/linux/instrumented.h:68 [inline]BUG: KASAN: slab-use-after-free in _test_bitinclude/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0net/bluetooth/l2cap_core.c:4260Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/arm/malidp: fix a possible null pointer dereferenceIn malidp_mw_connector_reset, new memory is allocated with kzalloc, butno check is performed. In order to prevent null pointer dereferencing,ensure that mw_state is checked before calling__drm_atomic_helper_connector_reset.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36270 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: tproxy: bail out if IP has been disabled on the devicesyzbot reports:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f][..]RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168__in_dev_get_rcu() can return NULL, so check for this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs: Ensure 'ib_sge list' is accessibleMove the declaration of the 'ib_sge list' variable outside the'always_invalidate' block to ensure it remains accessible for usethroughout the function.Previously, 'ib_sge list' was declared within the 'always_invalidate'block, limiting its accessibility, then caused a'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10This change ensures the variable is available for subsequent operationsthat require it.[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36479 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: bridge: add owner module and take its refcountThe current implementation of the fpga bridge assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the bridge ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_bridgestruct and use it to take the module's refcount. Modify the function forregistering a bridge to take an additional owner module parameter andrename it to avoid conflicts. Use the old function name for a helper macrothat automatically sets the module that registers the bridge as the owner.This ensures compatibility with existing low-level control modules andreduces the chances of registering a bridge without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga bridge.Other changes: opportunistically move put_device() from __fpga_bridge_get()to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity sincethe bridge device is taken in these functions.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()syzbot is able to trigger the following crash [1],caused by unsafe ip6_dst_idev() use.Indeed ip6_dst_idev() can return NULL, and must always be checked.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4cRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bdR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36908 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: do not WARN if iocg was already offlinedIn iocg_pay_debt(), warn is triggered if 'active_list' is empty, whichis intended to confirm iocg is active when it has debt. However, warncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0The warn in this situation is meaningless. Since this iocg is beingremoved, the state of the 'active_list' is irrelevant, and 'waitq_timer'is canceled after removing 'active_list' in ioc_pd_free(), which ensuresiocg is freed after iocg_waitq_timer_fn() returns.Therefore, add the check if iocg was already offlined to avoid warnwhen removing a blkcg or disk.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encryptedIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus ring buffer code could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the structvmbus_gpadl for the ring buffers to decide whether to free the memory.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Track decrypted status in vmbus_gpadlIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.In order to make sure callers of vmbus_establish_gpadl() andvmbus_teardown_gpadl() don't return decrypted/shared pages toallocators, add a field in struct vmbus_gpadl to keep track of thedecryption status of the buffers. This will allow the callers toknow if they should free or leak the pages.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip on writeback when it's not applicable[WHY]dynamic memory safety error detector (KASAN) catches and generates errormessages "BUG: KASAN: slab-out-of-bounds" as writeback connector does notsupport certain features which are not initialized.[HOW]Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: don't free NULL coalescing ruleIf the parsing fails, we can dereference a NULL pointer here.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Reapply "drm/qxl: simplify qxl_fence_wait"This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"and further debugging points to a possible circular locking dependencybetween the console_owner locking and the worker pool locking.Reverting the commit allows Steve's VM to boot to completion again.[ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:phonet: fix rtm_phonet_notify() skb allocationfill_route() stores three components in the skb:- struct rtmsg- RTA_DST (u8)- RTA_OIF (u32)Therefore, rtm_phonet_notify() should useNLMSG_ALIGN(sizeof(struct rtmsg)) +nla_total_size(1) +nla_total_size(4)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: Fix memory leak in tpm2_key_encode()'scratch' is never freed. Fix this by calling kfree() in the success, andin the error case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in:---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix division by zero in setup_dsc_configWhen slice_height is 0, the division by slice_height in the calculationof the number of slices will cause a division by zero driver crash. Thisleaves the kernel in a state that requires a reboot. This patch adds acheck to avoid the division by zero.The stack trace below is for the 6.8.4 Kernel. I reproduced the issue ona Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitorconnected via Thunderbolt. The amdgpu driver crashed with this exceptionwhen I rebooted the system with the monitor connected.kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpuAfter applying this patch, the driver no longer crashes when the monitoris connected and the system is rebooted. I believe this is the sameissue reported for 3113.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37021 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: manager: add owner module and take its refcountThe current implementation of the fpga manager assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the manager ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_managerstruct and use it to take the module's refcount. Modify the functions forregistering the manager to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the manager as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a manager without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga manager.Other changes: opportunistically move put_device() from __fpga_mgr_get() tofpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since themanager device is taken in these functions.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() isassigned to mhdp_state->current_mode, and there is a dereference of it indrm_mode_set_name(), which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate().Fix this bug add a check of mhdp_state->current_mode.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Add 0 size check to mtk_drm_gem_objAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM objectof 0 bytes. Currently, no such check exists and the kernel will panic ifa userspace application attempts to allocate a 0x0 GBM buffer.Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 andverifying that we now return EINVAL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38556 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Add a timeout to acquire the command queue semaphorePrevent forced completion handling on an entry that has not yet beenassigned an index, causing an out of bounds access on idx = -22.Instead of waiting indefinitely for the sem, blocking flow now waits forindex to be allocated or a sem acquisition timeout before beginning thetimer for FW completion.Kernel log example:mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38573 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cppc_cpufreq: Fix possible null pointer dereferencecppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called fromdifferent places with various parameters. So cpufreq_cpu_get() can returnnull as 'policy' in some circumstances.Fix this bug by adding null return check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38586 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r8169: Fix possible ring buffer corruption on fragmented Tx packets.An issue was found on the RTL8125b when transmitting small fragmentedpackets, whereby invalid entries were inserted into the transmit ringbuffer, subsequently leading to calls to dma_unmap_single() with a nulladdress.This was caused by rtl8169_start_xmit() not noticing changes to nr_fragswhich may occur when small packets are padded (to work around hardwarequirks) in rtl8169_tso_csum_v2().To fix this, postpone inspecting nr_frags until after any padding has beenapplied.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix possible use-after-free issue in ftrace_location()KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79The root cause is that, in lookup_rec(), ftrace record of some addressis being searched in ftrace pages of some module, but those ftrace pagesat the same time is being freed in ftrace_release_mod() as thecorresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free!To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix possible dead-lock in nr_rt_ioctl()syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)[1]WARNING: possible circular locking dependency detected6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted------------------------------------------------------syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK ***1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38619 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Check whether the media is initializedThe member "uzonesize" of struct alauda_info will remain 0if alauda_init_media() fails, potentially causing divide errorsin alauda_read_data() and alauda_write_lba().- Add a member "media_initialized" to struct alauda_info.- Change a condition in alauda_check_media() to ensure the first initialization.- Add an error check for the return value of alauda_init_media().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: stk1160: fix bounds checking in stk1160_copy_video()The subtract in this condition is reversed. The ->length is the lengthof the buffer. The ->bytesused is how many bytes we have copied thusfar. When the condition is reversed that means the result of thesubtraction is always negative but since it's unsigned then the resultis a very high positive value. That means the overflow check is nevertrue.Additionally, the ->bytesused doesn't actually work for this purposebecause we're not writing to "buf->mem + buf->bytesused". Instead, themath to calculate the destination where we are writing is a bitinvolved. You calculate the number of full lines already written,multiply by two, skip a line if necessary so that we start on an oddnumbered line, and add the offset into the line.To fix this buffer overflow, just take the actual destination where weare writing, if the offset is already out of bounds print an error andreturn. Otherwise, write up to buf->length bytes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:stm class: Fix a double free in stm_register_device()The put_device(&stm->dev) call will trigger stm_device_release() whichfrees "stm" so the vfree(stm) on the next line is a double free.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn't update the respective globalvariable and after insmod - rmmod - insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Lock port->lock when calling uart_handle_cts_change()uart_handle_cts_change() has to be called with port lock taken,Since we run it in a separate work, the lock may not be taken atthe time of running. Make sure that it's taken by explicitly doingthat. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: cadence: fix invalid PDI offsetFor some reason, we add an offset to the PDI, presumably to skip thePDI0 and PDI1 which are reserved for BPT.This code is however completely wrong and leads to an out-of-boundsaccess. We were just lucky so far since we used only a couple of PDIsand remained within the PDI array bounds.A Fixes: tag is not provided since there are no known platforms wherethe out-of-bounds would be accessed, and the initial code had problemsas well.A follow-up patch completely removes this useless offset.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38661 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ap: Fix crash in AP internal function modify_bitmap()A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oopsoccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.The fix is simple: use unsigned long values for the internal variables. Thecorrect checks are already in place in the function but a simple int forthe internal variables was used with the possibility to overflow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don't enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context") by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39488 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRYWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytesto bug_table entries, and as a result the last entry in a bug table willbe ignored, potentially leading to an unexpected panic(). All priorentries in the table will be handled correctly.The arm64 ABI requires that struct fields of up to 8 bytes arenaturally-aligned, with padding added within a struct such that structare suitably aligned within arrays.When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes }... with 12 bytes total, requiring 4-byte alignment.When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes }... with 8 bytes total, with 6 bytes of data and 2 bytes of trailingpadding, requiring 4-byte alginment.When we create a bug_entry in assembly, we align the start of the entryto 4 bytes, which implicitly handles padding for any prior entries.However, we do not align the end of the entry, and so whenCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing paddingbytes.For the main kernel image this is not a problem as find_bug() doesn'tdepend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug;However for modules, module_bug_finalize() depends on the trailingbytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);... and as the last bug_entry lacks the necessary padding bytes, this entrywill not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out;... which can lead to a kenrel panic due to an unhandled bug.This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL");... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39499 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vmci: prevent speculation leaks by sanitizing event in event_deliver()Coverity spotted that event_msg is controlled by user-space,event_msg->event_data.event is passed to event_deliver() and usedas an index without sanitization.This change ensures that the event index is sanitized to mitigate anypossibility of speculative information leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.Only compile tested, no access to HW.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39506 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packetIn lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,but then it is unconditionally passed to skb_add_rx_frag() which looksstrange and could lead to null pointer dereference.lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)In this path there is no code which sets pg_info->page to NULL.So this check looks unneeded and doesn't solve potential problem.But I guess the author had reason to add a check and I have no such cardand can't do real test.In addition, the code in the function liquidio_push_packet() inliquidio/lio_core.c does exactly the same.Based on this, I consider the most acceptable compromise solution toadjust this issue by moving skb_add_rx_frag() into conditional scope.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39509 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: remove unnecessary WARN_ON() in implement()Syzkaller hit a warning [1] in a call to implement() when tryingto write a value into a field of smaller size in an output report.Since implement() already has a warn message printed out with thehelp of hid_warn() and value in question gets trimmed with: ... value &= m; ...WARN_ON may be considered superfluous. Remove it to suppress futuresyzkaller triggers.[1]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863Modules linked in:CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863...Call Trace: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40904 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messagesThe syzbot fuzzer found that the interrupt-URB completion callback inthe cdc-wdm driver was taking too long, and the driver's immediateresubmission of interrupt URBs with -EPROTO status combined with thedummy-hcd emulation to cause a CPU lockup:cdc_wdm 1-1:1.0: nonzero urb status received: -71cdc_wdm 1-1:1.0: wdm_int_callback - 0 byteswatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idleModules linked in:irq event stamp: 73096hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline]hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline]softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Testing showed that the problem did not occur if the two errormessages -- the first two lines above -- were removed; apparently addingmaterial to the kernel log takes a surprisingly large amount of time.In any case, the best approach for preventing these lockups and toavoid spamming the log with thousands of error messages per second isto ratelimit the two dev_err() calls. Therefore we replace them withdev_err_ratelimited().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible race in __fib6_drop_pcpu_from()syzbot found a race in __fib6_drop_pcpu_from() [1]If compiler reads more than once (*ppcpu_rt),second read could read NULL, if another cpu clearsthe value in rt6_get_pcpu_route().Add a READ_ONCE() to prevent this race.Also add rcu_read_lock()/rcu_read_unlock() becausewe rely on RCU protection while dereferencing pcpu_rt.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48RSP: 0018:ffffc900040df070 EFLAGS: 00010206RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Lock wiphy in cfg80211_get_stationWiphy should be locked before calling rdev_get_station() (see lockdepassert in ieee80211_get_station()).This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)This happens because STA has time to disconnect and reconnect beforebatadv_v_elp_throughput_metric_update() delayed work gets scheduled. Inthis situation, ath10k_sta_state() can be in the middle of resettingarsta data when the work queue get chance to be scheduled and ends upaccessing it. Locking wiphy prevents that.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock tosynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called fromsoftirq context. However using only spin_lock() to get sta->ps_lock inieee80211_sta_ps_deliver_wakeup() does not prevent softirq to executeon this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try totake this same lock ending in deadlock. Below is an example of rcu stallthat arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raiseon the same CPU that is holding the lock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40929 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsIn some versions of cfg80211, the ssids poinet might be a valid one eventhough n_ssids is 0. Accessing the pointer in this case will cuase anout-of-bound access. Fix this by checking n_ssids first.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't read past the mfuart notifcationIn case the firmware sends a notification that claims it has more datathan it has, we will read past that was allocated for the notification.Remove the print of the buffer, we won't see it by default. If needed,we can see the content with tracing.This was reported by KFENCE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40942 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: mesh: Fix leak of mesh_preq_queue objectsThe hwmp code use objects of type mesh_preq_queue, added to a list inieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpathgets deleted, ex mesh interface is removed, the entries in that list willnever get cleaned. Fix this by flushing all corresponding items of thepreq_queue in mesh_path_flush_pending().This should take care of KASAN reports like this:unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure theloads and stores are atomic. In the extremely unlikely scenario thecompiler tears the stores, it's theoretically possible for KVM to attemptto get a vCPU using an out-of-bounds index, e.g. if the write is splitinto multiple 8-bit stores, and is paired with a 32-bit load on a VM with257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff];As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netns: Make get_net_ns() handle zero refcount netSyzkaller hit a warning:refcount_t: addition on 0; use-after-free.WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0Modules linked in:CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:refcount_warn_saturate+0xdf/0x1d0Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72acRDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? show_regs+0xa3/0xc0 ? __warn+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0 ? report_bug+0x1fc/0x2d0 ? refcount_warn_saturate+0xdf/0x1d0 ? handle_bug+0xa1/0x110 ? exc_invalid_op+0x3c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0 ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5b28f165d7Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 Kernel panic - not syncing: kernel: panic_on_warn set ...This is trigger as below: ns0 ns1tun_set_iff() //dev is tun0 tun->dev = dev//ip link set tun0 netns ns1 put_net() //ref is 0__tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //addition on 0Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00RSP: 0018:ffffc90000117378 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Avoid hw_desc array overrun in dw-axi-dmacI have a use case where nr_buffers = 3 and in which each descriptor is composed by 3segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()handles the hw_desc considering the descs_allocated, this scenario would result in akernel panic (hw_desc array will be overrun).To fix this, the proposal is to add a new member to the axi_dma_desc structure,where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it inaxi_desc_put() to handle the hw_desc array correctly.Additionally I propose to remove the axi_chan_start_first_queued() call after completingthe transfer, since it was identified that unbalance can occur (started descriptors canbe interrupted and transfer ignored due to DMA channel not being enabled).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40982 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40983 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: force a dst refcount before doing decryptionAs it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount beforeentering the xfrm type handlers"):"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."On TIPC decryption path it has the same problem, and skb_dst_force()should be called before doing decryption to avoid a possible crash.Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid"Info: mapping multiple BARs. Your kernel is fine.""). The initialpurpose of this commit was to stop memory mappings for operationregions from overlapping page boundaries, as it can trigger warningsif different page attributes are present.However, it was found that when this situation arises, mappingcontinues until the boundary's end, but there is still an attempt toread/write the entire length of the map, leading to a NULL pointerdeference. For example, if a four-byte mapping request is made butonly one byte is mapped because it hits the current page boundary'send, a four-byte read/write attempt is still made, resulting in a NULLpointer deference.Instead, map the entire length, as the ACPI specification does notmandate that it must be within the same page boundary. It ispermissible for it to be mapped across different regions.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()syzbot found hanging tasks waiting on rtnl_lock [1]A reproducer is available in the syzbot bug.When a request to add multiple actions with the same index is sent, thesecond request will block forever on the first request. This holdsrtnl_lock, and causes tasks to hang.Return -EAGAIN to prevent infinite looping, while keeping documentedbehavior.[1]INFO: task kworker/1:0:5088 blocked for more than 143 seconds.Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000Workqueue: events_power_efficient reg_check_chans_workCall Trace:context_switch kernel/sched/core.c:5409 [inline]__schedule+0xf15/0x5d00 kernel/sched/core.c:6746__schedule_loop kernel/sched/core.c:6823 [inline]schedule+0xe7/0x350 kernel/sched/core.c:6838schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895__mutex_lock_common kernel/locking/mutex.c:684 [inline]__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752wiphy_lock include/net/cfg80211.h:5953 [inline]reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()In the following concurrency we will access the uninitialized rs->lock:ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock hereand get the following dump_stack:=========================================================INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504[...]Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4][...]=========================================================Normally interval is 0 until s_msg_ratelimit_state is initialized, so___ratelimit() does nothing. But registering sysfs precedes initializingrs->lock, so it is possible to change rs->interval to a non-zero valuevia the msg_ratelimit_interval_ms interface of sysfs while rs->lock isuninitialized, and then a call to ext4_msg triggers the problem byaccessing an uninitialized rs->lock. Therefore register sysfs after allinitializations are complete to avoid such problems.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()xattr in ocfs2 maybe 'non-indexed', which saved with additional spacerequested. It's better to check if the memory is out of bound beforememcmp, although this possibility mainly comes from crafted poisonousimages.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: don't walk off the end of ealistAdd a check before visiting the members of ea tomake sure each ea stays within the ealist.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41027 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Fix userfaultfd_api to return EINVAL as expectedCurrently if we request a feature that is not set in the Kernel config wefail silently and return all the available features. However, the manpage indicates we should return an EINVAL.We need to fix this issue since we can end up with a Kernel warning shoulda program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel withthe config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptorSyzbot has identified a bug in usbcore (see the Closes: tag below)caused by our assumption that the reserved bits in an endpointdescriptor's bEndpointAddress field will always be 0. As a result ofthe bug, the endpoint_is_duplicate() routine in config.c (and possiblyother routines as well) may believe that two descriptors are fordistinct endpoints, even though they have the same direction andendpoint number. This can lead to confusion, including the bugidentified by syzbot (two descriptors with matching endpoint numbersand directions, where one was interrupt and the other was bulk).To fix the bug, we will clear the reserved bits in bEndpointAddresswhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1specs say these bits are "Reserved, reset to zero".) This requires usto make a copy of the descriptor earlier in usb_parse_endpoint() anduse the copy instead of the original when checking for duplicates.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw filesUse strnlen() instead of strlen() on the algorithm and coefficient namestring arrays in V1 wmfw files.In V1 wmfw files the name is a NUL-terminated string in a fixed-sizearray. cs_dsp should protect against overrunning the array if the NULterminator is missing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn't mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let's make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix possible deadlock in io_register_iowq_max_workers()The io_register_iowq_max_workers() function calls io_put_sq_data(),which acquires the sqd->lock without releasing the uring_lock.Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lockbefore acquiring sqd->lock"), this can lead to a potential deadlocksituation.To resolve this issue, the uring_lock is released before callingio_put_sq_data(), and then it is re-acquired after the function call.This change ensures that the locks are acquired in the correctorder, preventing the possibility of a deadlock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: block BH in ila_output()As explained in commit 1378817486d6 ("tipc: block BHbefore using dst_cache"), net/core/dst_cache.chelpers need to be called with BH disabled.ila_output() is called from lwtunnel_output()possibly from process context, and under rcu_read_lock().We might be interrupted by a softirq, re-enter ila_output()and corrupt dst_cache data structures.Fix the race by using local_bh_disable().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41088 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251xfd: fix infinite loop when xmit failsWhen the mcp251xfd_start_xmit() function fails, the driver stopsprocessing messages, and the interrupt routine does not return,running indefinitely even after killing the running application.Error messages:[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).... and repeat forever.The issue can be triggered when multiple devices share the same SPIinterface. And there is concurrent access to the bus.The problem occurs because tx_ring->head increments even ifmcp251xfd_start_xmit() fails. Consequently, the driver skips one TXpackage while still expecting a response inmcp251xfd_handle_tefif_one().Resolve the issue by starting a workqueue to write the tx objsynchronously if err = -EBUSY. In case of another error, decrementtx_ring->head, remove skb from the echo stack, and drop the message.[mkl: use more imperative wording in patch description]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix endpoint checking in cxacru_bind()Syzbot is still reporting quite an old issue [1] that occurs due toincomplete checking of present usb endpoints. As such, wrongendpoints types may be used at urb sumbitting stage which in turntriggers a warning in usb_submit_urb().Fix the issue by verifying that required endpoint types are presentfor both in and out endpoints, taking into account cmd endpoint type.Unfortunately, this patch has not been tested on real hardware.[1] Syzbot report:usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502...Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid to reuse `hctx` not removed from cpuhp callback listIf the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,otherwise use-after-free may be triggered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix possible double free in error handling pathWhen auxiliary_device_add() returns error and then callsauxiliary_device_uninit(), callback function adev_releasecalls kfree(madev). We shouldn't call kfree(madev) againin the error handling path. Set 'madev' to NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42076 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: can: j1939: Initialize unused data in j1939_send_one()syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()creates full frame including unused data, but it doesn't initializeit. This causes the kernel-infoleak issue. Fix this by initializingunused data.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 ___sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fBytes 12-15 of 16 are uninitializedMemory access of size 16 starts at ffff888120969690Data copied to user address 00000000200017c0CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/restrack: Fix potential invalid address accessstruct rdma_restrack_entry's kern_name was set to KBUILD_MODNAMEin ib_create_cq(), while if the module exited but forgot del thisrdma_restrack_entry, it would cause a invalid address access inrdma_restrack_clean() when print the owner of this rdma_restrack_entry.These code is used to help find one forgotten PD release in one of theULPs. But it is not needed anymore, so delete them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xdp: Remove WARN() from __xdp_reg_mem_model()syzkaller reports a warning in __xdp_reg_mem_model().The warning occurs only if __mem_id_init_hash_table() returns an error. Itreturns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly.The second case cannot happen since there is a static const rhashtable_paramsstruct with valid fields. So, warning is only triggered when there is aproblem with memory allocation.Thus, there is no sense in using WARN() to handle this error and it can besafely removed.WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: fsl-asoc-card: set priv->pdev before using itpriv->pdev pointer was set after being used infsl_asoc_card_audmux_init().Move this assignment at the start of the probe function, sosub-functions can correctly use pdev through priv.fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to thedev struct, used with dev_err macros.As priv is zero-initialised, there would be a NULL pointer dereference.Note that if priv->dev is dereferenced before assignment but never used,for example if there is no error to be printed, the driver won't crashprobably due to compiler optimisations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFERIn create_pinctrl(), pinctrl_maps_mutex is acquired before callingadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()calls pinctrl_free(). However, pinctrl_free() attempts to acquirepinctrl_maps_mutex, which is already held by create_pinctrl(), leading toa potential deadlock.This patch resolves the issue by releasing pinctrl_maps_mutex beforecalling pinctrl_free(), preventing the deadlock.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250_omap: Implementation of Errata i2310As per Errata i2310[0], Erroneous timeout can be triggered,if this Erroneous interrupt is not cleared then it may leadsto storm of interrupts, therefore apply Errata i2310 solution.[0] https://www.ti.com/lit/pdf/sprz536 page 23

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42101 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:inet_diag: Initialize pad field in struct inet_diag_req_v2KMSAN reported uninit-value access in raw_lookup() [1]. Diag for rawsockets uses the pad field in struct inet_diag_req_v2 for theunderlying protocol. This field corresponds to the sdiag_raw_protocolfield in struct inet_diag_req_raw.inet_diag_get_exact_compat() converts inet_diag_req toinet_diag_req_v2, but leaves the pad field uninitialized. So the issueoccurs when raw_lookup() accesses the sdiag_raw_protocol field.Fix this by initializing the pad field ininet_diag_get_exact_compat(). Also, do the same fix ininet_diag_dump_compat() to avoid the similar issue in the future.[1]BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42107 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't process extts if PTP is disabledThe ice_ptp_extts_event() function can race with ice_ptp_release() andresult in a NULL pointer dereference which leads to a kernel panic.Panic occurs because the ice_ptp_extts_event() function callsptp_clock_event() with a NULL pointer. The ice driver has alreadyreleased the PTP clock by the time the interrupt for the next externaltimestamp event occurs.To fix this, modify the ice_ptp_extts_event() function to check thePTP state and bail early if PTP is not ready.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()The following is emitted when using idxd (DSA) dmanegine as the datamover for ntb_transport that ntb_netdev uses.[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526[74412.556784] caller is netif_rx_internal+0x42/0x130[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024[74412.581699] Call Trace:[74412.584514] [74412.586933] dump_stack_lvl+0x55/0x70[74412.591129] check_preemption_disabled+0xc8/0xf0[74412.596374] netif_rx_internal+0x42/0x130[74412.600957] __netif_rx+0x20/0xd0[74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev][74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport][74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport][74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd][74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd][74412.634046] irq_thread_fn+0x21/0x60[74412.638134] ? irq_thread+0xa8/0x290[74412.642218] irq_thread+0x1a0/0x290[74412.646212] ? __pfx_irq_thread_fn+0x10/0x10[74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10[74412.656117] ? __pfx_irq_thread+0x10/0x10[74412.660686] kthread+0x100/0x130[74412.664384] ? __pfx_kthread+0x10/0x10[74412.668639] ret_from_fork+0x31/0x50[74412.672716] ? __pfx_kthread+0x10/0x10[74412.676978] ret_from_fork_asm+0x1a/0x30[74412.681457] The cause is due to the idxd driver interrupt completion handler usesthreaded interrupt and the threaded handler is not hard or soft interruptcontext. However __netif_rx() can only be called from interrupt context.Change the call to netif_rx() in order to allow completion via normalcontext for dmaengine drivers that utilize threaded irq handling.While the following commit changed from netif_rx() to __netif_rx(),baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),the change should've been a noop instead. However, the code precedes thisfix should've been using netif_rx_ni() or netif_rx_any_context().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM valuessyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUMto 2^31.We had a similar issue in sch_fq, fixed with commitd9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]Modules linked in:irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Workqueue: mld mld_ifc_workpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854sp : ffff800093d36700x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffffx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fcx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check pipe offset before setting vblankpipe_ctx has a size of MAX_PIPES so checking its index before accessingthe array.This fixes an OVERRUN issue reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check index msg_id before read or write[WHAT]msg_id is used as an array index and it cannot be a negative value, andtherefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).[HOW]Check whether msg_id is valid before reading and setting.This fixes 4 OVERRUN issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL pointer check for kzalloc[Why & How]Check return pointer of kzalloc before using it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Make qedf_execute_tmf() non-preemptibleStop calling smp_processor_id() from preemptible code inqedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42130 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc/nci: Add the inconsistency check between the input data length and countwrite$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf)Syzbot constructed a write() call with a data length of 3 bytes but a count valueof 15, which passed too little data to meet the basic requirements of the functionnci_rf_intf_activated_ntf_packet().Therefore, increasing the comparison between data length and count value to avoidproblems caused by inconsistent data length and count.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42139 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix improper extts handlingExtts events are disabled and enabled by the application ts2phc.However, in case where the driver is removed when the application isrunning, a specific extts event remains enabled and can cause a kernelcrash.As a side effect, when the driver is reloaded and application is startedagain, remaining extts event for the channel from a previous run willkeep firing and the message "extts on unexpected channel" might beprinted to the user.To avoid that, extts events shall be disabled when PTP is released.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnx2x: Fix multiple UBSAN array-index-out-of-boundsFix UBSAN warnings that occur when using a system with 32 physicalcpu cores or more, or when the user defines a number of Ethernetqueues greater than or equal to FP_SB_MAX_E1x using the num_queuesmodule parameter.Currently there is a read/write out of bounds that occurs on the array"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".Looking at the definition of the "struct stats_query_entry query" array:struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts andhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3meaning the array has a total size of 19.Since accesses to "struct stats_query_entry query" are offset-ted byBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernetqueues should not exceed FP_SB_MAX_E1x (16). However one of these queuesis reserved for FCOE and thus the number of Ethernet queues should be setto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) ifit is not.This is also described in a comment in the source code indrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definitionof FP_SB_MAX_E1x. Below is the part of this explanation that it importantfor this patch/* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */However this driver also supports NICs that use the E2 controller which canhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.Looking at the commits when the E2 support was added, it was originallyusing the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driverwas later updated to take full advantage of the E2 instead of having it belimited to the capabilities of the E1x. But as far as we can tell, thearray "stats_query_entry query" was still limited to using the FP-SBavailable to the E1x cards as part of an oversignt when the driver wasupdated to take full advantage of the E2, and now with the driver beingaware of the greater queue size supported by E2 NICs, it causes the UBSANwarnings seen in the stack traces below.This patch increases the size of the "stats_query_entry query" array byreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handleboth types of NICs.Stack traces:UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11index 20 is out of range for type 'stats_query_entry [19]'CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42154 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn't have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of clear-key structures on failureWipe all sensitive data from stack for all IOCTLs, which convert aclear-key into a protected- or secure-key.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe sensitive data on failureWipe sensitive data from stack also if the copy_to_user() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42158 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsReplace memzero_explicit() and kfree() with kfree_sensitive() to fixwarnings reported by Coccinelle:WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42162 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: Account for stopped queues when reading NIC statsWe now account for the fact that the NIC might send us stats for asubset of queues. Without this change, gve_get_ethtool_stats might makean invalid access on the priv->stats_report->stats array.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIObusses") mv88e6xxx_default_mdio_bus() has checked that thereturn value of list_first_entry() is non-NULL.This appears to be intended to guard against the list chip->mdios beingempty. However, it is not the correct check as the implementation oflist_first_entry is not designed to return NULL for empty lists.Instead, use list_first_entry_or_null() which does return NULL if thelist is empty.Flagged by Smatch.Compile tested only.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42228 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Validate payload length before processing blockMove the payload length check in cs_dsp_load() and cs_dsp_coeff_load()to be done before the block is processed.The check that the length of a block payload does not exceed the numberof remaining bytes in the firwmware file buffer was being done near theend of the loop iteration. However, some code before that check used thelength field without validating it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42238 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Return error if block header overflows fileReturn an error from cs_dsp_power_up() if a block header is longerthan the amount of data left in the file.The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loopwhile there was enough data left in the file for a valid region. Thisprotected against overrunning the end of the file data, but it didn'tabort the file processing with an error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: mos7840: fix crash on resumeSince commit c49cfa917025 ("USB: serial: use generic method if noalternative is provided in usb serial layer"), USB serial core calls thegeneric resume implementation when the driver has not provided one.This can trigger a crash on resume with mos7840 since support formultiple read URBs was added back in 2011. Specifically, both port readURBs are now submitted on resume for open ports, but the context pointerof the second URB is left set to the core rather than mos7840 portstructure.Fix this by implementing dedicated suspend and resume functions formos7840.Tested with Delock 87414 USB 2.0 to 4x serial adapter.[ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socketWhen using a BPF program on kernel_connect(), the call can return -EPERM. Thiscauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causingthe kernel to potentially freeze up.Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.ECONNREFUSED as error seems reasonable. For programs setting a different errorcan be out of reach (see handling in 4fbac77d2d09) in particular on kernelswhich do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -errinstead of allow boolean"), thus given that it is better to simply remap forconsistent behavior. UDP does handle EPERM in xs_udp_send_request().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42280 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: Fix a use after free in hfcmulti_tx()Don't dereference *sp after calling dev_kfree_skb(*sp).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a segment issue when downgrading gso_sizeLinearize the skb when downgrading gso_size because it may trigger aBUG_ON() later when the skb is segmented as described in [1,2].

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42283 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: nexthop: Initialize all fields in dumped nexthopsstruct nexthop_grp contains two reserved fields that are not initialized bynla_put_nh_group(), and carry garbage. This can be observed e.g. withstrace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52The fields are reserved and therefore not currently used. But as they are, theyleak kernel memory, and the fact they are not just zero complicates repurposingof the fields for new ends. Initialize the full structure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42284 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Return non-zero value from tipc_udp_addr2str() on errortipc_udp_addr2str() should return non-zero value if the UDP mediaaddress is invalid. Otherwise, a buffer overflow access can occur intipc_media_addr_printf(). Fix this by returning 1 on an invalid UDPmedia address.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix a use-after-free related to destroying CM IDsiw_conn_req_handler() associates a new struct rdma_id_private (conn_id) withan existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Makesure that cm_work_handler() does not trigger a use-after-free by onlyfreeing of the struct rdma_id_private after all pending work has finished.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42290 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/imx-irqsteer: Handle runtime power management correctlyThe power domain is automatically activated from clk_prepare(). However, oncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokessleeping functions, which triggers the 'scheduling while atomic' bug in thecontext switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chipcallbacks and handle power management in them as they are invoked fromnon-atomic context.[ tglx: Rewrote change log, added Fixes tag ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add a per-VF limit on number of FDIR filtersWhile the iavf driver adds a s/w limit (128) on the number of FDIRfilters that the VF can request, a malicious VF driver can request morethan that and exhaust the resources for other VFs.Add a similar limit in ice.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42295 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: handle inconsistent state in nilfs_btnode_create_block()Syzbot reported that a buffer state inconsistency was detected innilfs_btnode_create_block(), triggering a kernel bug.It is not appropriate to treat this inconsistency as a bug; it can occurif the argument block address (the buffer index of the newly createdblock) is a virtual block number and has been reallocated due tocorruption of the bitmap used to manage its allocation state.So, modify nilfs_btnode_create_block() and its callers to treat it as apossible filesystem error, rather than triggering a kernel bug.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: make sure the first directory block is not a holeThe syzbot constructs a directory that has no dirblock but is non-inline,i.e. the first directory block is a hole. And no errors are reported whencreating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported.After that, we get a directory block without '.' and '..' but with a validdentry. This may cause some code that relies on dot or dotdot (such asmake_indexed_dir()) to crash.Therefore when ext4_read_dirblock() finds that the first directory blockis a hole report that the filesystem is corrupted and return an error toavoid loading corrupted data from disk causing something bad.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42305 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: check dot and dotdot of dx_root before making dir indexedSyzbot reports a issue as follows:============================================BUG: unable to handle page fault for address: ffffed11022e24fePGD 23ffee067 P4D 23ffee067 PUD 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214[...]============================================The immediate cause of this problem is that there is only one valid dentryfor the block to be split during do_split, so split==0 results in out ofbounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295]The maximum length of a filename is 255 and the minimum block size is 1024,so it is always guaranteed that the number of entries is greater than orequal to 2 when do_split() is called.But syzbot's crafted image has no dot and dotdot in dir, and the dentrydistribution in dirblock is as follows: bus dentry1 hole dentry2 free|xx--|xx-------------|...............|xx-------------|...............|0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024So when renaming dentry1 increases its name_len length by 1, neither holenor free is sufficient to hold the new dentry, and make_indexed_dir() iscalled.In make_indexed_dir() it is assumed that the first two entries of thedirblock must be dot and dotdot, so bus and dentry1 are left in dx_rootbecause they are treated as dot and dotdot, and only dentry2 is movedto the new leaf block. That's why count is equal to 1.Therefore add the ext4_check_dx_root() helper function to add more sanitychecks to dot and dotdot before starting the conversion to avoid the aboveissue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid using corrupted block bitmap bufferWhen the filesystem block bitmap is corrupted, we detect the corruptionwhile loading the bitmap and fail the allocation with error. However thenext allocation from the same bitmap will notice the bitmap buffer isalready loaded and tries to allocate from the bitmap with mixed results(depending on the exact nature of the bitmap corruption). Fix theproblem by using BH_verified bit to indicate whether the bitmap is validor not.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42309 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modesIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42310 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modesIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: always initialize i_uid/i_gidAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()can safely skip setting them.Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values ofi_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid whenset_ownership() was not implemented. It also missed adjustingnet_ctl_set_ownership() to use the same default values in case thecomputation of a better value failed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Don't lose track of restrictions on cred_transferWhen a process' cred struct is replaced, this _almost_ always invokesthe cred_prepare LSM hook; but in one special case (whenKEYCTL_SESSION_TO_PARENT updates the parent's credentials), thecred_transfer LSM hook is used instead. Landlock only implements thecred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causesall information on Landlock restrictions to be lost.This basically means that a process with the ability to use the fork()and keyctl() syscalls can get rid of all Landlock restrictions onitself.Fix it by adding a cred_transfer hook that does the same thing as theexisting cred_prepare hook. (Implemented by having hook_cred_prepare()call hook_cred_transfer() so that the two functions are less likely toaccidentally diverge in the future.)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42321 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: flow_dissector: use DEBUG_NET_WARN_ON_ONCEThe following splat is easy to reproduce upstream as well as in -stablekernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net")but this complementary fix has been also suggested by Willem de Bruijnand it can be easily backported to -stable kernel which consists inusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splatgiven __skb_get_hash() is used by the nftables tracing infrastructure toto identify packets in traces.[69133.561393] ------------[ cut here ]------------[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/[...][69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ffff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28[69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0[69133.562040] Call Trace:[69133.562044] [69133.562049] ? __warn+0x9f/0x1a0[ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860[...][ 1211.841496] ? bpf_flow_dissect+0x160/0x160[ 1211.841753] __skb_get_hash+0x97/0x280[ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230[ 1211.841776] ? mod_find+0xbf/0xe0[ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0[ 1211.841798] ? bpf_ksym_find+0x56/0xe0[ 1211.841807] ? __rcu_read_unlock+0x2a/0x70[ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables][ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables][ 1211.841964] ? get_stack_info+0x2b/0x80[ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables][ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42322 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: properly dereference pe in ip_vs_add_serviceUse pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: missing check virtioTwo missing check in virtio_net_hdr_to_skb() allowed syzbotto crash kernels again1. After the skb_segment function the buffer may become non-linear(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywherethe __skb_linearize function will not be executed, then the buffer willremain non-linear. Then the condition (offset >= skb_headlen(skb))becomes true, which causes WARN_ON_ONCE in skb_checksum_help.2. The struct sk_buff and struct virtio_net_hdr members must bemathematically related.(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) may be 0 if division is without remainder.offset+2 (4191) > skb_headlen() (1116)WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Modules linked in:CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 efRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045cR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105dFS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bFound by Linux Verification Center (linuxtesting.org) with Syzkaller

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kvm: s390: Reject memory region operations for ucontrol VMsThis change rejects the KVM_SET_USER_MEMORY_REGION andKVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 andwould thus result in a null pointer dereference further in.Memory management needs to be performed in userspace and using theioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGIONand KVM_SET_USER_MEMORY_REGION2.[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix a possible null pointer dereferenceIn function lpfc_xcvr_data_show, the memory allocation with kmalloc mightfail, thereby making rdp_context a null pointer. In the following contextand functions that use this pointer, there are dereferencing operations,leading to null pointer dereference.To fix this issue, a null pointer check should be added. If it is null,use scnprintf to notify the user and return len.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()Instead of getting the epc_features from pci_epc_get_features() API, usethe cached pci_epf_test::epc_features value to avoid the NULL check. Sincethe NULL check is already performed in pci_epf_test_bind(), having one morecheck in pci_epf_test_core_init() is redundant and it is not possible tohit the NULL pointer dereference.Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"flag"), 'epc_features' got dereferenced without the NULL check, leading tothe following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)Thus, remove the redundant NULL check and also use the epc_features::{msix_capable/msi_capable} flags directly to avoid local variables.[kwilczynski: commit log]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix infinite loop when replaying fast_commitWhen doing fast_commit replay an infinite loop may occur due to anuninitialized extent_status struct. ext4_ext_determine_insert_hole() doesnot detect the replay and calls ext4_es_find_extent_range(), which willreturn immediately without initializing the 'es' variable.Because 'es' contains garbage, an integer overflow may happen causing aninfinite loop in this function, easily reproducible using fstest generic/039.This commit fixes this issue by unconditionally initializing the structurein function ext4_es_find_extent_range().Thanks to Zhang Yi, for figuring out the real problem!

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Handle invalid decoder vsiHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsiis valid for future use.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43832 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/uv: Don't call folio_wait_writeback() without a folio referencefolio_wait_writeback() requires that no spinlocks are held and thata folio reference is held, as documented. After we dropped the PTL, thefolio could get freed concurrently. So grab a temporary reference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xdp: fix invalid wait context of page_pool_destroy()If the driver uses a page pool, it creates a page pool withpage_pool_create().The reference count of page pool is 1 as default.A page pool will be destroyed only when a reference count reaches 0.page_pool_destroy() is used to destroy page pool, it decreases areference count.When a page pool is destroyed, ->disconnect() is called, which ismem_allocator_disconnect().This function internally acquires mutex_lock().If the driver uses XDP, it registers a memory model withxdp_rxq_info_reg_mem_model().The xdp_rxq_info_reg_mem_model() internally increases a page poolreference count if a memory model is a page pool.Now the reference count is 2.To destroy a page pool, the driver should call both page_pool_destroy()and xdp_unreg_mem_model().The xdp_unreg_mem_model() internally calls page_pool_destroy().Only page_pool_destroy() decreases a reference count.If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), wewill face an invalid wait context warning.Because xdp_unreg_mem_model() calls page_pool_destroy() withrcu_read_lock().The page_pool_destroy() internally acquires mutex_lock().Splat looks like:=============================[ BUG: Invalid wait context ]6.10.0-rc6+ #4 Tainted: G W-----------------------------ethtool/1806 is trying to lock:ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150other info that might help us debug this:context-{5:5}3 locks held by ethtool/1806:stack backtrace:CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fedHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021Call Trace:dump_stack_lvl+0x7e/0xc0__lock_acquire+0x1681/0x4de0? _printk+0x64/0xe0? __pfx_mark_lock.part.0+0x10/0x10? __pfx___lock_acquire+0x10/0x10lock_acquire+0x1b3/0x580? mem_allocator_disconnect+0x73/0x150? __wake_up_klogd.part.0+0x16/0xc0? __pfx_lock_acquire+0x10/0x10? dump_stack_lvl+0x91/0xc0__mutex_lock+0x15c/0x1690? mem_allocator_disconnect+0x73/0x150? __pfx_prb_read_valid+0x10/0x10? mem_allocator_disconnect+0x73/0x150? __pfx_llist_add_batch+0x10/0x10? console_unlock+0x193/0x1b0? lockdep_hardirqs_on+0xbe/0x140? __pfx___mutex_lock+0x10/0x10? tick_nohz_tick_stopped+0x16/0x90? __irq_work_queue_local+0x1e5/0x330? irq_work_queue+0x39/0x50? __wake_up_klogd.part.0+0x79/0xc0? mem_allocator_disconnect+0x73/0x150mem_allocator_disconnect+0x73/0x150? __pfx_mem_allocator_disconnect+0x10/0x10? mark_held_locks+0xa5/0xf0? rcu_is_watching+0x11/0xb0page_pool_release+0x36e/0x6d0page_pool_destroy+0xd7/0x440xdp_unreg_mem_model+0x1a7/0x2a0? __pfx_xdp_unreg_mem_model+0x10/0x10? kfree+0x125/0x370? bnxt_free_ring.isra.0+0x2eb/0x500? bnxt_free_mem+0x5ac/0x2500xdp_rxq_info_unreg+0x4a/0xd0bnxt_free_mem+0x1356/0x2500bnxt_close_nic+0xf0/0x3b0? __pfx_bnxt_close_nic+0x10/0x10? ethnl_parse_bit+0x2c6/0x6d0? __pfx___nla_validate_parse+0x10/0x10? __pfx_ethnl_parse_bit+0x10/0x10bnxt_set_features+0x2a8/0x3e0__netdev_update_features+0x4dc/0x1370? ethnl_parse_bitset+0x4ff/0x750? __pfx_ethnl_parse_bitset+0x10/0x10? __pfx___netdev_update_features+0x10/0x10? mark_held_locks+0xa5/0xf0? _raw_spin_unlock_irqrestore+0x42/0x70? __pm_runtime_resume+0x7d/0x110ethnl_set_features+0x32d/0xa20To fix this problem, it uses rhashtable_lookup_fast() instead ofrhashtable_lookup() with rcu_read_lock().Using xa without rcu_read_lock() here is safe.xa is freed by __xdp_mem_allocator_rcu_free() and this is called bycall_rcu() of mem_xa_remove().The mem_xa_remove() is called by page_pool_destroy() if a referencecount reaches 0.The xa is already protected by the reference count mechanism well in thecontrol plane.So removing rcu_read_lock() for page_pool_destroy() is safe.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ("net: Use nested-BH locking fornapi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it's running in NAPI contexteven when it's not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43837 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXTWhen loading a EXT program without specifying `attr->attach_prog_fd`,the `prog->aux->dst_prog` will be null. At this time, callingresolve_prog_type() anywhere will result in a null pointer dereference.Example stack trace:[ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004[ 8.108262] Mem abort info:[ 8.108384] ESR = 0x0000000096000004[ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits[ 8.108722] SET = 0, FnV = 0[ 8.108827] EA = 0, S1PTW = 0[ 8.108939] FSC = 0x04: level 0 translation fault[ 8.109102] Data abort info:[ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000[ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000[ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 8.112783] Modules linked in:[ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1[ 8.113230] Hardware name: linux,dummy-virt (DT)[ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0[ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8[ 8.113798] sp : ffff80008283b9f0[ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001[ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000[ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000[ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff[ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720[ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720[ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4[ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f[ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c[ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000[ 8.114126] Call trace:[ 8.114159] may_access_direct_pkt_data+0x24/0xa0[ 8.114202] bpf_check+0x3bc/0x28c0[ 8.114214] bpf_prog_load+0x658/0xa58[ 8.114227] __sys_bpf+0xc50/0x2250[ 8.114240] __arm64_sys_bpf+0x28/0x40[ 8.114254] invoke_syscall.constprop.0+0x54/0xf0[ 8.114273] do_el0_svc+0x4c/0xd8[ 8.114289] el0_svc+0x3c/0x140[ 8.114305] el0t_64_sync_handler+0x134/0x150[ 8.114331] el0t_64_sync+0x168/0x170[ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)[ 8.118672] ---[ end trace 0000000000000000 ]---One way to fix it is by forcing `attach_prog_fd` non-empty whenbpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`API broken which use verifier log to probe prog type and will lognothing if we reject invalid EXT prog before bpf_check().Another way is by adding null check in resolve_prog_type().The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve toprog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wantedto correct type resolution for BPF_PROG_TYPE_TRACING programs. Beforethat, the type resolution of BPF_PROG_TYPE_EXT prog actually followsthe logic below: prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type;It implies that when EXT program is not yet attached to `dst_prog`,the prog type should be EXT itself. This code worked fine in the past.So just keep using it.Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog`is not present in resolve_prog_type().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bna: adjust 'name' buf size of bna_tcb and bna_ccb structuresTo have enough space to write all possible sprintf() args. Currently'name' size is 16, but the first '%s' specifier may already need atleast 16 characters, since 'bnad->netdev->name' is used there.For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16And replace sprintf with snprintf.Detected using the static analysis tool - Svace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: virt_wifi: avoid reporting connection success with wrong SSIDWhen user issues a connection with a different SSID than the onevirt_wifi has advertised, the __cfg80211_connect_result() willtrigger the warning: WARN_ON(bss_not_found).The issue is because the connection code in virt_wifi does notcheck the SSID from user space (it only checks the BSSID), andvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESSeven if the SSID is different from the one virt_wifi has advertised.Eventually cfg80211 won't be able to find the cfg80211_bss and generatethe warning.Fixed it by checking the SSID (from user space) in the connection code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma: fix call order in dmam_free_coherentdmam_free_coherent() frees a DMA allocation, which makes thefreed vaddr available for reuse, then calls devres_destroy()to remove and free the data structure used to track the DMAallocation. Between the two calls, it is possible for aconcurrent task to make an allocation with the same vaddrand add it to the devres list.If this happens, there will be two entries in the devres listwith the same vaddr and devres_destroy() can free the wrongentry, triggering the WARN_ON() in dmam_match.Fix by destroying the devres entry before freeing the DMAallocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix array-index-out-of-bounds in diFree

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43860 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: imx_rproc: Skip over memory region when node value is NULLIn imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just countsnumber of phandles. But phandles may be empty. So of_parse_phandle() inthe parsing loop (0 < a < nph) may return NULL which is later dereferenced.Adjust this issue by adding NULL-return check.Found by Linux Verification Center (linuxtesting.org) with SVACE.[Fixed title to fit within the prescribed 70-75 charcters]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a deadlock in dma buf fence pollingIntroduce a version of the fence ops that on release doesn't removethe fence from the pending list, and thus doesn't require a lock tofix poll->fence wait->fence unref deadlocks.vmwgfx overwrites the wait callback to iterate over the list of allfences and update their status, to do that it holds a lock to preventthe list modifcations from other threads. The fence destroy callbackboth deletes the fence and removes it from the list of pendingfences, for which it holds a lock.dma buf polling cb unrefs a fence after it's been signaled: so the pollcalls the wait, which signals the fences, which are being destroyed.The destruction tries to acquire the lock on the pending fences listwhich it can never get because it's held by the wait from which itwas called.Old bug, but not a lot of userspace apps were using dma-buf pollinginterfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Always drain health in shutdown callbackThere is no point in recovery during device shutdown. if healthwork started need to wait for it to avoid races and NULL pointeraccess.Hence, drain health WQ on shutdown callback.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix refcount underflowCalling nouveau_bo_ref() on a nouveau_bo without initializing it (andhence the backing ttm_bo) leads to a refcount underflow.Instead of calling nouveau_bo_ref() in the unwind path ofdrm_gem_object_init(), clean things up manually.(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:devres: Fix memory leakage caused by driver API devm_free_percpu()It will cause memory leakage when use driver API devm_free_percpu()to free memory allocated by devm_alloc_percpu(), fixed by usingdevres_release() instead of devres_destroy() within devm_free_percpu().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup under heavy CEQE loadCEQEs are handled in interrupt handler currently. This may cause theCPU core staying in interrupt context too long and lead to soft lockupunder heavy load.Handle CEQEs in BH workqueue and set an upper limit for the number ofCEQE handled by a single call of work handler.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost/vsock: always initialize seqpacket_allowThere are two issues around seqpacket_allow:1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized.2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this).To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled incfg80211_calculate_bitrate_he(), leading to below warning:kernel: invalid HE MCS: bw:6, ru:6kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43880 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_erp: Fix object nesting warningACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former cancontain more ACLs (i.e., tc filters), but the number of masks in eachregion (i.e., tc chain) is limited.In order to mitigate the effects of the above limitation, the deviceallows filters to share a single mask if their masks only differ in upto 8 consecutive bits. For example, dst_ip/25 can be represented usingdst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on thenumber of masks being used (and therefore does not support maskaggregation), but can contain a limited number of filters.The driver uses the "objagg" library to perform the mask aggregation bypassing it objects that consist of the filter's mask and whether thefilter is to be inserted into the A-TCAM or the C-TCAM since filters indifferent TCAMs cannot share a mask.The set of created objects is dependent on the insertion order of thefilters and is not necessarily optimal. Therefore, the driver willperiodically ask the library to compute a more optimal set ("hints") bylooking at all the existing objects.When the library asks the driver whether two objects can be aggregatedthe driver only compares the provided masks and ignores the A-TCAM /C-TCAM indication. This is the right thing to do since the goal is tomove as many filters as possible to the A-TCAM. The driver also forbidstwo identical masks from being aggregated since this can only happen ifone was intentionally put in the C-TCAM to avoid a conflict in theA-TCAM.The above can result in the following set of hints:H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + deltaH3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + deltaAfter getting the hints from the library the driver will start migratingfilters from one region to another while consulting the computed hintsand instructing the device to perform a lookup in both regions duringthe transition.Assuming a filter with mask X is being migrated into the A-TCAM in thenew region, the hints lookup will return H1. Since H2 is the parent ofH1, the library will try to find the object associated with it andcreate it if necessary in which case another hints lookup (recursive)will be performed. This hints lookup for {mask Y, A-TCAM} will eitherreturn H2 or H3 since the driver passes the library an object comparisonfunction that ignores the A-TCAM / C-TCAM indication.This can eventually lead to nested objects which are not supported bythe library [1].Fix by removing the object comparison function from both the driver andthe library as the driver was the only user. That way the lookup willonly return exact matches.I do not have a reliable reproducer that can reproduce the issue in atimely manner, but before the fix the issue would reproduce in severalminutes and with the fix it does not reproduce in over an hour.Note that the current usefulness of the hints is limited because theyinclude the C-TCAM indication and represent aggregation that cannotactually happen. This will be addressed in net-next.[1]WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0Modules linked in:CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0[...]Call Trace: __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null pointer deref in dcn20_resource.cFixes a hang thats triggered when MPV is run on a DCN401 dGPU:mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=alland then enabling fullscreen playback (double click on the video)The following calltrace will be seen:[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 181.843997] #PF: supervisor instruction fetch in kernel mode[ 181.844003] #PF: error_code(0x0010) - not-present page[ 181.844009] PGD 0 P4D 0[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018[ 181.844044] RIP: 0010:0x0[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0[ 181.844141] Call Trace:[ 181.844146] [ 181.844153] ? show_regs+0x6d/0x80[ 181.844167] ? __die+0x24/0x80[ 181.844179] ? page_fault_oops+0x99/0x1b0[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0[ 181.844204] ? exc_page_fault+0x83/0x1b0[ 181.844216] ? asm_exc_page_fault+0x27/0x30[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu][ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu][ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu][ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu][ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu][ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference for smu7optimize the code to avoid pass a null pointer (hwmgr->backend)to function smu7_update_edc_leakage_table.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: prevent potential speculation leaks in gpio_device_get_desc()Userspace may trigger a speculative read of an address outside the gpiodescriptor array.Users can do that by calling gpio_ioctl() with an offset out of range.Offset is copied from user and then used as an array index to getthe gpio descriptor without sanitization in gpio_device_get_desc().This change ensures that the offset is sanitized by usingarray_index_nospec() to mitigate any possibility of speculativeinformation leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: wait for previous gc cycles when removing portsyzbot hit a use-after-free[1] which is caused because the bridge doesn'tmake sure that all previous garbage has been collected when removing aport. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still runningMake sure all previous gc cycles have finished by using flush_work beforefreeing the port.[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix null-ptr-deref in reuseport_add_sock().syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb inreuseport_add_sock(). [0]The repro first creates a listener with SO_REUSEPORT. Then, it createsanother listener on the same port and concurrently closes the firstlistener.The second listen() calls reuseport_add_sock() with the first listener assk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,but the close() does clear it by reuseport_detach_sock().The problem is SCTP does not properly synchronise reuseport_alloc(),reuseport_add_sock(), and reuseport_detach_sock().The caller of reuseport_alloc() and reuseport_{add,detach}_sock() mustprovide synchronisation for sockets that are classified into the samereuseport group.Otherwise, such sockets form multiple identical reuseport groups, andall groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packetsAlso, the reported null-ptr-deref could occur.TCP/UDP guarantees that would not happen by holding the hash bucket lock.Let's apply the locking strategy to __sctp_hash_endpoint() and__sctp_unhash_endpoint().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f24e46039b9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42cR13:---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44939 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix null ptr deref in dtInsertEntry[syzbot reported]general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713...[Analyze]In dtInsertEntry(), when the pointer h has the same value as p, after writingname in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause thepreviously true judgment "p->header.flag & BT-LEAF" to change to no after writingthe name operation, this leads to entering an incorrect branch and accessing theuninitialized object ih when judging this condition for the second time.[Fix]After got the page, check freelist first, if freelist == 0 then exit dtInsert()and return -EINVAL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use helper function to calculate expect IDDelete expectation path is missing a call to the nf_expect_get_id()helper function to calculate the expectation ID, otherwise LSB of theexpectation object address is leaked to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mtrr: Check if fixed MTRRs exist before saving themMTRRs have an obsolete fixed variant for fine grained caching controlof the 640K-1MB region that uses separate MSRs. This fixed variant hasa separate capability bit in the MTRR capability MSR.So far all x86 CPUs which support MTRR have this separate bit set, so itwent unnoticed that mtrr_save_state() does not check the capability bitbefore accessing the fixed MTRR MSRs.Though on a CPU that does not support the fixed MTRR capability thisresults in a #GP. The #GP itself is harmless because the RDMSR fault ishandled gracefully, but results in a WARN_ON().Add the missing capability check to prevent this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: fix invalid FIFO access with special register setWhen enabling access to the special register set, Receiver time-out andRHR interrupts can happen. In this case, the IRQ handler will try to readfrom the FIFO thru the RHR register at address 0x00, but address 0x00 ismapped to DLL register, resulting in erroneous FIFO reading.Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register setFix the problem by claiming the efr_lock mutex when accessing the Specialregister set.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44954 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: Fix racy access to midibufThere can be concurrent accesses to line6 midibuf from both the URBcompletion callback and the rawmidi API access. This could be a causeof KMSAN warning triggered by syzkaller below (so put as reported-byhere).This patch protects the midibuf call of the former code path with aspinlock for avoiding the possible races.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/smt: Fix unbalance sched_smt_present dec/incI got the following warn report while doing stress test:jump label: negative count!WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),the cpu offline failed, but sched_smt_present is decremented beforecalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, sofix it by incrementing sched_smt_present in the error path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Prevent release of buffer in I/OWhen a task waiting for completion of a Store Data operation isinterrupted, an attempt is made to halt this operation. If this attemptfails due to a hardware or firmware problem, there is a chance that theSCLP facility might store data into buffers referenced by the originaloperation at a later time.Handle this situation by not releasing the referenced data buffers ifthe halt attempt fails. For current use cases, this might result in aleak of few pages of memory in case of a rare hardware/firmwaremalfunction.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44971 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()bcm_sf2_mdio_register() calls of_phy_find_device() and thenphy_device_remove() in a loop to remove existing PHY devices.of_phy_find_device() eventually calls bus_find_device(), which callsget_device() on the returned struct device * to increment the refcount.The current implementation does not decrement the refcount, which causesmemory leak.This commit adds the missing phy_device_free() call to decrement therefcount via put_device() to balance the refcount.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsIf the dpu_format_populate_layout() fails, then FB is prepared, but notcleaned up. This ends up leaking the pin_count on the GEM object andcauses a splat during DRM file closure:msm_obj->pin_countWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc[...]Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194irq event stamp: 129818hardirqs last enabled at (129817): [] console_unlock+0x118/0x124hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8csoftirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8softirqs last disabled at (129785): [] __do_softirq+0x14/0x20Patchwork: https://patchwork.freedesktop.org/patch/600714/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible UAF in ip6_finish_output2()If skb_expand_head() returns NULL, skb has been freedand associated dst/idev could also have been freed.We need to hold rcu_read_lock() to make sure the dst andassociated idev are alive.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Fix out-of-bound accessIf an ATU violation was caused by a CPU Load operation, the SPID couldbe larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix xfrm real_dev null pointer dereferenceWe shouldn't set real_dev to NULL because packets can be in transit andxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assumereal_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix null pointer deref in bond_ipsec_offload_okWe must check if there is an active slave before dereferencing the pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix a deadlock problem when config TC during resettingWhen config TC during the reset process, may cause a deadlock, the flow isas below: pf reset start | v ......setup tc | | v v DOWN: napi_disable()napi_disable()(skip) | | | v v ...... ...... | | v |napi_enable() | v UINIT: netif_napi_del() | v ...... | v INIT: netif_napi_add() | v ...... global reset start | | v v UP: napi_enable()(skip) ...... | | v v ...... napi_disable()In reset process, the driver will DOWN the port and then UINIT, in thiscase, the setup tc process will UP the port before UINIT, so cause theproblem. Adds a DOWN process in UINIT to fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: idt77252: prevent use after free in dequeue_rx()We can't dereference "skb" after calling vcc->push() because the skbis released.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44999 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: pull network headers in gtp_dev_xmit()syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]We must make sure the IPv4 or Ipv6 header is pulled in skb->headbefore accessing fields in them.Use pskb_inet_may_pull() to fix this issue.[1]BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: xillybus: Don't destroy workqueue from work item running on itTriggered by a kref decrement, destroy_workqueue() may be called fromwithin a work item for destroying its own workqueue. This illegalsituation is averted by adding a module-global workqueue for exclusiveuse of the offending work item. Other work items continue to be queuedon per-device workqueues to ensure performance.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45008 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: MT - limit max slotssyzbot is reporting too large allocation at input_mt_init_slots(), fornum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).Since nobody knows possible max slots, this patch chose 1024.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: xillybus: Check USB endpoints when probing deviceEnsure, as the driver probes the device, that all endpoints that thedriver may attempt to access exist and are of the correct type.All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint ataddress 1. This is verified in xillyusb_setup_base_eps().On top of that, a XillyUSB device may have additional Bulk OUTendpoints. The information about these endpoints' addresses is deducedfrom a data structure (the IDT) that the driver fetches from the devicewhile probing it. These endpoints are checked in setup_channels().A XillyUSB device never has more than one IN endpoint, as all datatowards the host is multiplexed in this single Bulk IN endpoint. This iswhy setup_channels() only checks OUT endpoints.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45018 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: initialise extack before useFix missing initialisation of extack in flow offload.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45025 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHAREcopy_fd_bitmaps(new, old, count) is expected to copy the firstcount/BITS_PER_LONG bits from old->full_fds_bits[] and fillthe rest with zeroes. What it does is copying enough words(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.That works fine, *if* all bits past the cutoff point areclear. Otherwise we are risking garbage from the last wordwe'd copied.For most of the callers that is true - expand_fdtable() hascount equal to old->max_fds, so there's no open descriptorspast count, let alone fully occupied words in ->open_fds[],which is what bits in ->full_fds_bits[] correspond to.The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),which is the smallest multiple of BITS_PER_LONG that covers allopened descriptors below max_fds. In the common case (copying onfork()) max_fds is ~0U, so all opened descriptors will be belowit and we are fine, by the same reasons why the call in expand_fdtable()is safe.Unfortunately, there is a case where max_fds is less than thatand where we might, indeed, end up with junk in ->full_fds_bits[] -close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors.In that case we end up with observably wrong behaviour - e.g. spawna child with CLONE_FILES, get all descriptors in range 0..127 open,then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) endingup with descriptor #128, despite #64 being observably not open.The minimally invasive fix would be to deal with that in dup_fd().If this proves to add measurable overhead, we can go that way, butlet's try to fix copy_fd_bitmaps() first.* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).* make copy_fd_bitmaps() take the bitmap size in words, rather thanbits; it's 'count' argument is always a multiple of BITS_PER_LONG,so we are not losing any information, and that way we can use thesame helper for all three bitmaps - compiler will see that countis a multiple of BITS_PER_LONG for the large ones, so it'll generateplain memcpy()+memset().Reproducer added to tools/testing/selftests/core/close_range_test.c

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45029 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: Do not mark ACPI devices as irq safeOn ACPI machines, the tegra i2c module encounters an issue due to amutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xferThe problem arises because during __pm_runtime_resume(), the spinlock&dev->power.lock is acquired before rpm_resume() is called. Later,rpm_resume() invokes acpi_subsys_runtime_resume(), which relies onmutexes, triggering the error.To address this issue, devices on ACPI are now marked as not IRQ-safe,considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46677 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix a potential NULL pointer dereferenceWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns aNULL pointer, but its callers only check for error pointers thus missthe NULL pointer case.Fix it by returning an error pointer with the error code carried fromsockfd_lookup().(I found this bug during code inspection.)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereference in pcs_get_function()pinmux_generic_get_function() can return NULL and the pointer 'function'was dereferenced without checking against NULL. Add checking of pointer'function' in pcs_get_function().Found by code review.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46686 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()This happens when called from SMB2_read() while using rdmaand reaching the rdma_readwrite_threshold.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: cmd-db: Map shared memory as WC, not WBLinux does not write into cmd-db region. This region of memory is writeprotected by XPU. XPU may sometime falsely detect clean cache evictionas "write" into the write protected region leading to secure interruptwhich causes an endless loop somewhere in Trust Zone.The only reason it is working right now is because Qualcomm Hypervisormaps the same region as Non-Cacheable memory in Stage 2 translationtables. The issue manifests if we want to use another hypervisor (likeXen or KVM), which does not know anything about those specific mappings.Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WCremoves dependency on correct mappings in Stage 2 tables. This patchfixes the issue by updating the mapping to MEMREMAP_WC.I tested this on SA8155P with Xen.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don't bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don't do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3On a system with a GICv3, if a guest hasn't been configured withGICv3 and that the host is not capable of GICv2 emulation,a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.We therefore try to emulate the SGI access, only to hit a NULLpointer as no private interrupt is allocated (no GIC, remember?).The obvious fix is to give the guest what it deserves, in theshape of a UNDEF exception.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event->mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46714 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip wbscl_set_scaler_filter if filter is nullCallers can pass null in filter (i.e. from returned from the functionwbscl_get_filter_coeffs_16p) and a null check is added to ensure that isnot the case.This fixes 4 NULL_RETURNS issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver: iio: add missing checks on iio_info's callback accessSome callbacks from iio_info structure are accessed without any check, soif a driver doesn't implement them trying to access the correspondingsysfs entries produce a kernel oops such as:[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute[...][ 2203.783416] Call trace:[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0[ 2203.830363] Code: bad PC value[ 2203.832695] ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: SHAMPO, Fix incorrect page releaseUnder the following conditions:1) No skb created yet2) header_size == 0 (no SHAMPO header)3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page)a new skb is formed with a page that is NOT a SHAMPO header page (itis a regular data page). Further down in the same function(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page fromheader_index is released. This is wrong and it leads to SHAMPO headerpages being released more than once.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix possible NULL pointer dereferenceprofile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is madefrom __create_missing_ancestors(..) and 'ent->old' is NULL inaa_replace_profiles(..).In that case, it must return an error code and the code, -ENOENT representsits state that the path of its parent is not existed yet.BUG: kernel NULL pointer dereference, address: 0000000000000030PGD 0 P4D 0PREEMPT SMP PTICPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80RIP: 0033:0x7be9f211c574Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesasCR2: 0000000000000030---[ end trace 0000000000000000 ]---RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix mc_data out-of-bounds read warningClear warning that read mc_data[i-1] may out-of-bounds.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix ucode out-of-bounds read warningClear warning that read ucode[] may out-of-bounds.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_numberCheck the fb_channel_number range to avoid the array out-of-boundsread error

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds write warningCheck the ring type value to fix the out-of-boundswrite warning

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46731 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix the Out-of-bounds read warningusing index i - 1U may beyond element indexfor mc_data[] when i = 0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Assign linear_pitch_alignment even for VM[Description]Assign linear_pitch_alignment so we don't cause a divide by 0error in VM environments

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: sanity check symbolic link sizeSyzkiller reports a "KMSAN: uninit-value in pick_link" bug.This is caused by an uninitialised page, which is ultimately causedby a corrupted symbolic link size read from disk.The reason why the corrupted symlink size causes an uninitialisedpage is due to the following sequence of events:1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.This patch adds a sanity check which checks that the symboliclink size is not larger than expected.--V2: fix spelling mistake.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - reject requests with unreasonable number of slotsWhen exercising uinput interface syzkaller may try setting up devicewith a really large number of slots, which causes memory allocationfailure in input_mt_init_slots(). While this allocation failure ishandled properly and request is rejected, it results in syzkallerreports. Additionally, such request may put undue burden on thesystem which will try to free a lot of memory for a bogus request.Fix it by limiting allowed number of slots to 100. This can easilybe extended if we see devices that can track more than 100 contacts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46751 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,aborting the transaction and logging an error message.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46752 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BUG_ON() with error handling at update_ref_for_cow()Instead of a BUG_ON() just return an error, log an error message andabort the transaction in case we find an extent buffer belonging to therelocation tree that doesn't have the full backref flag set. This isunexpected and should never happen (save for bugs or a potential badmemory).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle errors from btrfs_dec_ref() properlyIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This isincorrect, we have proper error handling here, return the error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46755 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()mwifiex_get_priv_by_id() returns the priv pointer corresponding tothe bss_num and bss_type, but without checking if the priv is actuallycurrently in use.Unused priv pointers do not have a wiphy attached to them which canlead to NULL pointer dereferences further down the callstack. Fixthis by returning only used priv pointers which have priv->bss_modeset to something else than NL80211_IFTYPE_UNSPECIFIED.Said NULL pointer dereference happened when an Accesspoint was startedwith wpa_supplicant -i mlan0 with this config:network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678"}When waiting for the AP to be established, interrupting wpa_supplicantwith and starting it again this happens:| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140| Mem abort info:| ESR = 0x0000000096000004| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x04: level 0 translation fault| Data abort info:| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000| CM = 0, WnR = 0, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18| Hardware name: somemachine (DT)| Workqueue: events sdio_irq_work| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]| sp : ffff8000818b3a70| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000| Call trace:| mwifiex_get_cfp+0xd8/0x15c [mwifiex]| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]| mwifiex_process_event+0x110/0x238 [mwifiex]| mwifiex_main_process+0x428/0xa44 [mwifiex]| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]| process_sdio_pending_irqs+0x64/0x1b8| sdio_irq_work+0x4c/0x7c| process_one_work+0x148/0x2a0| worker_thread+0x2fc/0x40c| kthread+0x110/0x114| ret_from_fork+0x10/0x20| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)| ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pci/hotplug/pnv_php: Fix hotplug driver crash on PowernvThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernelcrash when we try to hot-unplug/disable the PCIe switch/bridge fromthe PHB.The crash occurs because although the MSI data structure has beenreleased during disable/hot-unplug path and it has been assignedwith NULL, still during unregistration the code was again trying toexplicitly disable the MSI which causes the NULL pointer dereference andkernel crash.The patch fixes the check during unregistration path to prevent invokingpci_disable_msi/msix() since its data structure is already freed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] [ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add netif_device_attach/detach into PF reset flowEthtool callbacks can be executed while reset is in progress and try toaccess deleted resources, e.g. getting coalesce settings can result in aNULL pointer dereference seen below.Reproduction steps:Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net//device/resetwhen reset is in progress try to get coalesce settings using ethtool: # ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0Call Trace:ice_get_coalesce+0x17/0x30 [ice]coalesce_prepare_data+0x61/0x80ethnl_default_doit+0xde/0x340genl_family_rcv_msg_doit+0xf2/0x150genl_rcv_msg+0x1b3/0x2c0netlink_rcv_skb+0x5b/0x110genl_rcv+0x28/0x40netlink_unicast+0x19c/0x290netlink_sendmsg+0x222/0x490__sys_sendto+0x1df/0x1f0__x64_sys_sendto+0x24/0x30do_syscall_64+0x82/0x160entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7faee60d8e27Calling netif_device_detach() before reset makes the net core not callthe driver when ethtool command is issued, the attempt to execute anethtool command during reset will result in the following message: netlink error: No such deviceinstead of NULL pointer dereference. Once reset is done andice_rebuild() is executing, the netif_device_attach() is called to allowfor ethtool operations to occur again in a safe manner.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Remove proc entry when dev is unregistered.syzkaller reported a warning in bcm_connect() below. [0]The repro calls connect() to vxcan1, removes vxcan1, and callsconnect() with ifindex == 0.Calling connect() for a BCM socket allocates a proc entry.Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().However, removing the bound device resets bcm_sk(sk)->bound to 0in bcm_notify().The 2nd connect() tries to allocate a proc entry with the samename and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking theoriginal proc entry.Since the proc entry is available only for connect()ed sockets,let's clean up the entry when the bound netdev is unregistered.[0]:proc_dir_entry 'can-bcm/2456' already registeredWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375Modules linked in:CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ecFS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fbd708b0e5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5dRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid excessive partition lengthsAvoid mounting filesystems where the partition would overflow the32-bits used for block number. Also refuse to mount filesystems wherethe partition length is so large we cannot safely index bits in ablock bitmap.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: protect references to superblock parameters exposed in sysfsThe superblock buffers of nilfs2 can not only be overwritten at runtimefor modifications/repairs, but they are also regularly swapped, replacedduring resizing, and even abandoned when degrading to one side due tobacking device issues. So, accessing them requires mutual exclusion usingthe reader/writer semaphore "nilfs->ns_sem".Some sysfs attribute show methods read this superblock buffer without thenecessary mutual exclusion, which can cause problems with pointerdereferencing and memory access, so fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix missing cleanup on rollforward recovery errorIn an error injection test of a routine for mount-time recovery, KASANfound a use-after-free bug.It turned out that if data recovery was performed using partial logscreated by dsync writes, but an error occurred before starting the logwriter to create a recovered checkpoint, the inodes whose data had beenrecovered were left in the ns_dirty_files list of the nilfs object andwere not freed.Fix this issue by cleaning up inodes that have read the recovery data ifthe recovery routine fails midway before the log writer starts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: call nf_unregister_net_hooks() soonersyzbot found an use-after-free Read in ila_nf_input [1]Issue here is that ila_xlat_exit_net() frees the rhashtable,then call nf_unregister_net_hooks().It should be done in the reverse way, with a synchronize_rcu().This is a good match for a pre_exit() method.[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)page_type: 0xbfffffff(buddy)raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: fix return value of tcp_bpf_sendmsg()When we cork messages in psock->cork, the last message triggers theflushing will result in sending a sk_msg larger than the currentmessage size. In this case, in tcp_bpf_send_verdict(), 'copied' becomesnegative at least in the following case:468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta); // <==== HERE473 return -EACCES;Therefore, it could lead to the following BUG with a proper value of'copied' (thanks to syzbot). We should not use negative 'copied' as areturn value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix checks for huge PMDsPatch series "userfaultfd: fix races around pmd_trans_huge() check", v2.The pmd_trans_huge() code in mfill_atomic() is wrong in three differentways depending on kernel version:1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr().3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong.I decided to write two separate fixes for these (one fix for bugs 1+2, onefix for bug 3), so that the first fix can be backported to kernelsaffected by bugs 1+2.This patch (of 2):This fixes two issues.I discovered that the following race can occur: mfill_atomic other thread ============ ============ pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd))I have experimentally verified this in a kernel with extra mdelay() calls;the BUG_ON(pmd_none(*dst_pmd)) triggers.On kernels newer than commit 0d940a9b270b ("mm/pgtable: allowpte_offset_map[_lock]() to fail"), this can't lead to anything worse thana BUG_ON(), since the page table access helpers are actually designed todeal with page tables concurrently disappearing; but on older kernels(<=6.4), I think we could probably theoretically race past the twoBUG_ON() checks and end up treating a hugepage as a page table.The second issue is that, as Qi Zheng pointed out, there are other typesof huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs(in particular, migration PMDs).On <=6.4, this is worse than the first issue: If mfill_atomic() runs on aPMD that contains a migration entry (which just requires winning a single,fairly wide race), it will pass the PMD to pte_offset_map_lock(), whichassumes that the PMD points to a page table.Breakage follows: First, the kernel tries to take the PTE lock (which willcrash or maybe worse if there is no "struct page" for the address bits inthe migration entry PMD - I think at least on X86 there usually is nocorresponding "struct page" thanks to the PTE inversion mitigation, amd64looks different).If that didn't crash, the kernel would next try to write a PTE into whatit wrongly thinks is a page table.As part of fixing these issues, get rid of the check for pmd_trans_huge()before __pte_alloc() - that's redundant, we're going to have to check forthat after the __pte_alloc() anyway.Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_openThe mcp251x_hw_wake() function is called with the mpc_lock mutex held anddisables the interrupt handler so that no interrupts can be processed whilewaking the device. If an interrupt has already occurred then waiting forthe interrupt handler to complete will deadlock because it will be tryingto acquire the same mutex.CPU0 CPU1---- ----mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlockUse disable_irq_nosync() instead because the interrupt handler doeseverything while holding the mutex so it doesn't matter if it's stillrunning.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: dapm: Fix UAF for snd_soc_pcm_runtime objectWhen using kernel with the following extra config, - CONFIG_KASAN=y - CONFIG_KASAN_GENERIC=y - CONFIG_KASAN_INLINE=y - CONFIG_KASAN_VMALLOC=y - CONFIG_FRAME_WARN=4096kernel detects that snd_pcm_suspend_all() access a freed'snd_soc_pcm_runtime' object when the system is suspended, whichleads to a use-after-free bug:[ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270[ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330[ 52.047785] Call trace:[ 52.047787] dump_backtrace+0x0/0x3c0[ 52.047794] show_stack+0x34/0x50[ 52.047797] dump_stack_lvl+0x68/0x8c[ 52.047802] print_address_description.constprop.0+0x74/0x2c0[ 52.047809] kasan_report+0x210/0x230[ 52.047815] __asan_report_load1_noabort+0x3c/0x50[ 52.047820] snd_pcm_suspend_all+0x1a8/0x270[ 52.047824] snd_soc_suspend+0x19c/0x4e0The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' beforemaking any access. So we need to always set 'substream->runtime' to NULLeverytime we kfree() it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: added NULL check at start of dc_validate_stream[Why]prevent invalid memory access[How]check if dc and stream are NULL

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check BIOS images before it is usedBIOS images may fail to load and null checks are added before they areused.This fixes 6 NULL_RETURNS issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box[Why]Coverity reports OVERRUN warning. soc.num_states couldbe 40. But array range of bw_params->clk_table.entries is 8.[How]Assert if soc.num_states greater than 8.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entryIn a review discussion of the changes to support vCPU hotplug wherea check was added on the GICC being enabled if was online, it wasnoted that there is need to map back to the cpu and use that to indexinto a cpumask. As such, a valid ID is needed.If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possiblefor the entry in cpu_madt_gicc[cpu] == NULL. This function wouldthen cause a NULL pointer dereference. Whilst a path to triggerthis has not been established, harden this caller against thepossibility.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46826 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ELF: fix kernel.randomize_va_space double readELF loader uses "randomize_va_space" twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched: sch_cake: fix bulk flow accounting logic for host fairnessIn sch_cake, we keep track of the count of active bulk flows per host,when running in dst/src host fairness mode, which is used as theround-robin weight when iterating through flows. The count of activebulk flows is updated whenever a flow changes state.This has a peculiar interaction with the hash collision handling: when ahash collision occurs (after the set-associative hashing), the state ofthe hash bucket is simply updated to match the new packet that collided,and if host fairness is enabled, that also means assigning new per-hoststate to the flow. For this reason, the bulk flow counters of thehost(s) assigned to the flow are decremented, before new state isassigned (and the counters, which may not belong to the same hostanymore, are incremented again).Back when this code was introduced, the host fairness mode was alwaysenabled, so the decrement was unconditional. When the configurationflags were introduced the *increment* was made conditional, butthe *decrement* was not. Which of course can lead to a spuriousdecrement (and associated wrap-around to U16_MAX).AFAICT, when host fairness is disabled, the decrement and wrap-aroundhappens as soon as a hash collision occurs (which is not that common initself, due to the set-associative hashing). However, in most cases thisis harmless, as the value is only used when host fairness mode isenabled. So in order to trigger an array overflow, sch_cake has to firstbe configured with host fairness disabled, and while running in thismode, a hash collision has to occur to cause the overflow. Then, theqdisc has to be reconfigured to enable host fairness, which leads to thearray out-of-bounds because the wrapped-around value is retained andused as an array index. It seems that syzbot managed to trigger this,which is quite impressive in its own right.This patch fixes the issue by introducing the same conditional check ondecrement as is used on increment.The original bug predates the upstreaming of cake, but the commit listedin the Fixes tag touched that code, meaning that this patch won't applybefore that.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: clean up our handling of refs == 0 in snapshot deleteIn reada we BUG_ON(refs == 0), which could be unkind since we aren'tholding a lock on the extent leaf and thus could get a transientincorrect answer. In walk_down_proc we also BUG_ON(refs == 0), whichcould happen if we have extent tree corruption. Change that to return-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,however we return -EIO, which -EUCLEAN is a more appropriate error code.Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convertthat to proper error handling. Also adjust the error message so we canactually do something with the information.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()We handle errors here properly, ENOMEM isn't fatal, return the error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_infoThe MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and theroutine unconditionally frees submitted mailbox commands regardless ofreturn status. The issue is that for MBX_TIMEOUT cases, when firmwarereturns SFP information at a later time, that same mailbox memory regionreferences previously freed memory in its cmpl routine.Fix by adding checks for the MBX_TIMEOUT return code. During mailboxresource cleanup, check the mbox flag to make sure that the wait did nottimeout. If the MBOX_WAKE flag is not set, then do not free the resourcesbecause it will be freed when firmware completes the mailbox at a latertime in its cmpl routine.Also, increase the timeout from 30 to 60 seconds to accommodate bootscripts requiring longer timeouts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Limit the period on HaswellRunning the ltp test cve-2015-3290 concurrently reports the followingwarnings.perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330Thanks to Thomas Gleixner's analysis, the issue is caused by the lowinitial period (1) of the frequency estimation algorithm, which triggersthe defects of the HW, specifically erratum HSW11 and HSW143. (For thedetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)The HSW11 requires a period larger than 100 for the INST_RETIRED.ALLevent, but the initial period in the freq mode is 1. The erratum is thesame as the BDM11, which has been supported in the kernel. A minimumperiod of 128 is enforced as well on HSW.HSW143 is regarding that the fixed counter 1 may overcount 32 with theHyper-Threading is enabled. However, based on the test, the hardwarehas more issues than it tells. Besides the fixed counter 1, the message'interrupt took too long' can be observed on any counter which was armedwith a period < 32 and two events expired in the same NMI. A minimumperiod of 32 is enforced for the rest of the events.The recommended workaround code of the HSW143 is not implemented.Because it only addresses the issue for the fixed counter. It bringsextra overhead through extra MSR writing. No related overcounting issuehas been reported so far.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: heaps: Fix off-by-one in CMA heap fault handlerUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:Don't track CMA dma-buf pages under RssFile") it was possible to obtaina mapping larger than the buffer size via mremap and bypass the overflowcheck in dma_buf_mmap_internal. When using such a mapping to attempt tofault past the end of the buffer, the CMA heap fault handler also checksthe fault offset against the buffer size, but gets the boundary wrong by1. Fix the boundary check so that we don't read off the end of the pagesarray and insert an arbitrary page in the mapping.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: nxp-fspi: fix the KASAN report out-of-bounds bugChange the memcpy length to fix the out-of-bounds issue when writing thedata that is not 4 byte aligned to TX FIFO.To reproduce the issue, write 3 bytes data to NOR chip.dd if=3b of=/dev/mtd0[ 36.926103] ==================================================================[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455[ 36.946721][ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)[ 36.961260] Call trace:[ 36.963723] dump_backtrace+0x90/0xe8[ 36.967414] show_stack+0x18/0x24[ 36.970749] dump_stack_lvl+0x78/0x90[ 36.974451] print_report+0x114/0x5cc[ 36.978151] kasan_report+0xa4/0xf0[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838[ 36.990800] spi_mem_exec_op+0x8ec/0xd30[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0[ 36.999323] spi_mem_dirmap_write+0x238/0x32c[ 37.003710] spi_nor_write_data+0x220/0x374[ 37.007932] spi_nor_write+0x110/0x2e8[ 37.011711] mtd_write_oob_std+0x154/0x1f0[ 37.015838] mtd_write_oob+0x104/0x1d0[ 37.019617] mtd_write+0xb8/0x12c[ 37.022953] mtdchar_write+0x224/0x47c[ 37.026732] vfs_write+0x1e4/0x8c8[ 37.030163] ksys_write+0xec/0x1d0[ 37.033586] __arm64_sys_write+0x6c/0x9c[ 37.037539] invoke_syscall+0x6c/0x258[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c[ 37.046244] do_el0_svc+0x44/0x5c[ 37.049589] el0_svc+0x38/0x78[ 37.052681] el0t_64_sync_handler+0x13c/0x158[ 37.057077] el0t_64_sync+0x190/0x194[ 37.060775][ 37.062274] Allocated by task 455:[ 37.065701] kasan_save_stack+0x2c/0x54[ 37.069570] kasan_save_track+0x20/0x3c[ 37.073438] kasan_save_alloc_info+0x40/0x54[ 37.077736] __kasan_kmalloc+0xa0/0xb8[ 37.081515] __kmalloc_noprof+0x158/0x2f8[ 37.085563] mtd_kmalloc_up_to+0x120/0x154[ 37.089690] mtdchar_write+0x130/0x47c[ 37.093469] vfs_write+0x1e4/0x8c8[ 37.096901] ksys_write+0xec/0x1d0[ 37.100332] __arm64_sys_write+0x6c/0x9c[ 37.104287] invoke_syscall+0x6c/0x258[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c[ 37.112972] do_el0_svc+0x44/0x5c[ 37.116319] el0_svc+0x38/0x78[ 37.119401] el0t_64_sync_handler+0x13c/0x158[ 37.123788] el0t_64_sync+0x190/0x194[ 37.127474][ 37.128977] The buggy address belongs to the object at ffff00081037c2a0[ 37.128977] which belongs to the cache kmalloc-8 of size 8[ 37.141177] The buggy address is located 0 bytes inside of[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)[ 37.153465][ 37.154971] The buggy address belongs to the physical page:[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)[ 37.175149] page_type: 0xfdffffff(slab)[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000[ 37.194553] page dumped because: kasan: bad access detected[ 37.200144][ 37.201647] Memory state around the buggy address:[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc[ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc[ 37.228186] ^[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.246962] ==============================================================---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_socket: fix sk refcount leaksWe must put 'sk' reference before returning.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix bridge mode operations when there are no VFsCurrently, trying to set the bridge mode attribute when numvfs=0 leads to acrash:bridge link set dev eth2 hwmode vepa[ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030[...][ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core][...][ 168.976037] Call Trace:[ 168.976188] [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core][ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core][ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0[ 168.979714] rtnetlink_rcv_msg+0x159/0x400[ 168.980451] netlink_rcv_skb+0x54/0x100[ 168.980675] netlink_unicast+0x241/0x360[ 168.980918] netlink_sendmsg+0x1f6/0x430[ 168.981162] ____sys_sendmsg+0x3bb/0x3f0[ 168.982155] ___sys_sendmsg+0x88/0xd0[ 168.985036] __sys_sendmsg+0x59/0xa0[ 168.985477] do_syscall_64+0x79/0x150[ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 168.987773] RIP: 0033:0x7f8f7950f917(esw->fdb_table.legacy.vepa_fdb is null)The bridge mode is only relevant when there are multiple functions perport. Therefore, prevent setting and getting this setting when there are noVFs.Note that after this change, there are no settings to change on the PFinterface using `bridge link` when there are no VFs, so the interface nolonger appears in the `bridge link` output.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: Fix uaf in __timer_delete_syncThere are two paths to access mptcp_pm_del_add_timer, result in a racecondition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry)In remove_anno_list_by_saddr(running on CPU2), after leaving the criticalzone protected by "pm.lock", the entry will be released, which leads to theoccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).Keeping a reference to add_timer inside the lock, and callingsk_stop_timer_sync() with this reference, instead of "entry->add_timer".Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,do not directly access any members of the entry outside the pm lock, whichcan avoid similar "entry->x" uaf.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: panasonic-laptop: Fix SINF array out of bounds accessesThe panasonic laptop code in various places uses the SINF array with indexvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF arrayis big enough.Not all panasonic laptops have this many SINF array entries, for examplethe Toughbook CF-18 model only has 10 SINF array entries. So it onlysupports the AC+DC brightness entries and mute.Check that the SINF array has a minimum size which covers all AC+DCbrightness entries and refuse to load if the SINF array is smaller.For higher SINF indexes hide the sysfs attributes when the SINF arraydoes not contain an entry for that attribute, avoiding show()/store()accessing the array out of bounds and add bounds checking to the probe()and resume() code accessing these.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: stm32/cryp - call finalize with bh disabledThe finalize operation in interrupt mode produce a produces a spinlockrecursion warning. The reason is the fact that BH must be disabledduring this process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy->enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late. After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47670 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_xattr_find_entry()Add a paranoia check to make sure it doesn't stray beyond valid memoryregion containing ocfs2 xattr entries when scanning for a match. It willprevent out-of-bound access in case of crafted images.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47678 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: change the order of rate limitsICMP messages are ratelimited :After the blamed commits, the two rate limiters are applied in this order:1) host wide ratelimit (icmp_global_allow())2) Per destination ratelimit (inetpeer based)In order to avoid side-channels attacks, we need to applythe per destination check first.This patch makes the following change :1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3)2) The per destination limit is checked/updated. This might add a new node in inetpeer tree.3) icmp_global_consume() consumes tokens if prior operations succeeded.This means that host wide ratelimit is still effectivein keeping inetpeer tree small even under DDOS.As a bonus, I removed icmp_global.lock as the fast pathcan use a lock-free operation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47692 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: return -EINVAL when namelen is 0When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it mayresult in namelen being 0, which will cause memdup_user() to returnZERO_SIZE_PTR.When we access the name.data that has been assigned the value ofZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference istriggered.[ T1205] ==================================================================[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205[ T1205][ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014[ T1205] Call Trace:[ T1205] dump_stack+0x9a/0xd0[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260[ T1205] __kasan_report.cold+0x34/0x84[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260[ T1205] kasan_report+0x3a/0x50[ T1205] nfs4_client_to_reclaim+0xe9/0x260[ T1205] ? nfsd4_release_lockowner+0x410/0x410[ T1205] cld_pipe_downcall+0x5ca/0x760[ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0[ T1205] ? down_write_killable_nested+0x170/0x170[ T1205] ? avc_policy_seqno+0x28/0x40[ T1205] ? selinux_file_permission+0x1b4/0x1e0[ T1205] rpc_pipe_write+0x84/0xb0[ T1205] vfs_write+0x143/0x520[ T1205] ksys_write+0xc9/0x170[ T1205] ? __ia32_sys_read+0x50/0x50[ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110[ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110[ T1205] do_syscall_64+0x33/0x40[ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1[ T1205] RIP: 0033:0x7fdbdb761bc7[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000[ T1205] ==================================================================Fix it by checking namelen.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix potential invalid pointer dereference in blk_add_partitionThe blk_add_partition() function initially used a single if-condition(IS_ERR(part)) to check for errors when adding a partition. This wasmodified to handle the specific case of -ENXIO separately, allowing thefunction to proceed without logging the error in this case. However,this change unintentionally left a path where md_autodetect_dev()could be called without confirming that part is a valid pointer.This commit separates the error handling logic by splitting theinitial if-condition, improving code readability and handling specificerror scenarios explicitly. The function now distinguishes the generalerror case from -ENXIO without altering the existing behavior ofmd_autodetect_dev() calls.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,as spotted by syzbot:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8cR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f1acc77def9Code: Unable to access opcode bytes at 0x7f1acc77decf.RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in:---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0R---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()Since '__dev_queue_xmit()' should be called with interrupts enabled,the following backtrace:ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)issues the warning (as reported by syzbot reproducer):WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120Fix this by implementing a two-phase skb reclamation in'ieee80211_do_stop()', where actual work is performedoutside of a section with interrupts disabled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - inject error before stopping queueThe master ooo cannot be completely closed when theaccelerator core reports memory error. Therefore, the driverneeds to inject the qm error to close the master ooo. Currently,the qm error is injected after stopping queue, memory may bereleased immediately after stopping queue, causing the device toaccess the released memory. Therefore, error is injected to close masterooo before stopping queue to ensure that the device does not accessthe released memory.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabledFix missuse of spin_lock_irq()/spin_unlock_irq() whenspin_lock_irqsave()/spin_lock_irqrestore() was hold.This was discovered through the lock debugging, and the correspondinglog is as follows:raw_local_irq_restore() called with IRQs enabledWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40...Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47736 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: handle overlapped pclusters out of crafted images properlysyzbot reported a task hang issue due to a deadlock case where it iswaiting for the folio lock of a cached folio that will be used forcache I/Os.After looking into the crafted fuzzed image, I found it's formed withseveral overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384...Here, extent 0/1 are physically overlapped although it's entirely_impossible_ for normal filesystem images generated by mkfs.First, managed folios containing compressed data will be marked asup-to-date and then unlocked immediately (unlike in-place folios) whencompressed I/Os are complete. If physical blocks are not submitted inthe incremental order, there should be separate BIOs to avoid dependencyissues. However, the current code mis-arranges z_erofs_fill_bio_vec()and BIO submission which causes unexpected BIO waits.Second, managed folios will be connected to their own pclusters forefficient inter-queries. However, this is somewhat hard to implementeasily if overlapped big pclusters exist. Again, these only appear infuzzed images so let's simply fall back to temporary short-lived pagesfor correctness.Additionally, it justifies that referenced managed folios cannot betruncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidyup `struct z_erofs_bvec`") for simplicity although it shouldn't be anydifference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47738 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't use rate mask for offchannel TX eitherLike the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask forscanning"), ignore incorrect settings to avoid no supported rate warningreported by syzbot.The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:fix default HE tx bitrate mask in 2G band"), which however correctsbitmask of HE MCS and recognizes correctly settings of empty legacy rateplus HE MCS rate instead of returning -EINVAL.As suggestions [1], follow the change of SCAN TX to consider this case ofoffchannel TX as well.[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47739 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: use integer wrap around to prevent deadlock on seq_nr overflowWhen submitting more than 2^32 padata objects to padata_do_serial, thecurrent sorting implementation incorrectly sorts padata objects withoverflowed seq_nr, causing them to be placed before existing objects inthe reorder list. This leads to a deadlock in the serialization processas padata_find_next cannot match padata->seq_nr and pd->processedbecause the padata instance with overflowed seq_nr will be selectednext.To fix this, we use an unsigned integer wrap around to correctly sortpadata objects in scenarios with integer overflow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cxgb4: Added NULL check for lookup_atidThe lookup_atid() function can return NULL if the ATID isinvalid or does not exist in the identifier table, whichcould lead to dereferencing a null pointer without acheck in the `act_establish()` and `act_open_rpl()` functions.Add a NULL check to prevent null pointer dereferencing.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-48881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Clean up TPM space after command failuretpm_dev_transmit prepares the TPM space before attempting commandtransmission. However if the command fails no rollback of thispreparation is done. This can result in transient handles being leakedif the device is subsequently closed with no further commands performed.Fix this by flushing the space in the event of command transmissionfailure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()The kref_put() function will call nport->release if the refcount drops tozero. The nport->release release function is _efc_nport_free() which frees"nport". But then we dereference "nport" on the next line which is a useafter free. Re-order these lines to avoid the use after free.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling codefrom control queue handler") a null pointer dereference bug can betriggered when guest sends an SCSI AN request.In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with`&v_req.tmf.lun[1]` within a switch-case block and is then passed tovhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, fora `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` isset to NULL in this branch. Later, in vhost_scsi_get_req(),`vc->target` is dereferenced without being checked, leading to a nullpointer dereference bug. This bug can be triggered from guest.When this bug occurs, the vhost_worker process is killed while holding`vq->mutex` and the corresponding tpg will remain occupiedindefinitely.Below is the KASAN report:Oops: general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vhost_scsi_get_req+0x165/0x3a0Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 0048 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b604 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00RSP: 0018:ffff888017affb50 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350... ---[ end trace 0000000000000000 ]---Let's add a check in vhost_scsi_get_req.[whitespace fixes]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: update orig_path in ext4_find_extent()In ext4_find_extent(), if the path is not big enough, we free it and set*orig_path to NULL. But after reallocating and successfully initializingthe path, we don't update *orig_path, in which case the caller gets avalid path but a NULL ppath, and this may cause a NULL pointer dereferenceor a path memory leak. For example:ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference!==================================================================BUG: kernel NULL pointer dereference, address: 0000000000000010CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847RIP: 0010:ext4_split_extent_at+0x6d/0x560Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0[...]==================================================================Therefore, *orig_path is updated when the extent lookup succeeds, so thatthe caller can safely use path or *ppath.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double brelse() the buffer of the extents pathIn ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has beenreleased, otherwise it may be released twice. An example of what triggersthis is as follows: split2 map split1|--------|-------|--------|ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twiceFinally got the following WARRNING when removing the buffer from lru:============================================VFS: brelse: Trying to free free bufferWARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716RIP: 0010:__brelse+0x58/0x90Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]============================================

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: aovid use-after-free in ext4_ext_insert_extent()As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path isreallocated in ext4_ext_create_new_leaf(), we'll use the stale path andcause UAF. Below is a sample trace with dummy values:ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr==================================================================BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800[...]Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]==================================================================So use *ppath to update the path to avoid the above problem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49886 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bugAttaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds".kasan report:[ 19.411889] ==================================================================[ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113[ 19.417368][ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10[ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022[ 19.422687] Call Trace:[ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80[ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.428694] print_report+0x19d/0x52e[ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.433539] kasan_report+0xf0/0x170[ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10[ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common][ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common][ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360[ 19.444797] cpuhp_invoke_callback+0x221/0xec0[ 19.446337] cpuhp_thread_fun+0x21b/0x610[ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10[ 19.449354] smpboot_thread_fn+0x2e7/0x6e0[ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10[ 19.452405] kthread+0x29c/0x350[ 19.453817] ? __pfx_kthread+0x10/0x10[ 19.455253] ret_from_fork+0x31/0x70[ 19.456685] ? __pfx_kthread+0x10/0x10[ 19.458114] ret_from_fork_asm+0x1a/0x30[ 19.459573] [ 19.460853][ 19.462055] Allocated by task 1198:[ 19.463410] kasan_save_stack+0x30/0x50[ 19.464788] kasan_save_track+0x14/0x30[ 19.466139] __kasan_kmalloc+0xaa/0xb0[ 19.467465] __kmalloc+0x1cd/0x470[ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common][ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr][ 19.471670] do_one_initcall+0xa4/0x380[ 19.472903] do_init_module+0x238/0x760[ 19.474105] load_module+0x5239/0x6f00[ 19.475285] init_module_from_file+0xd1/0x130[ 19.476506] idempotent_init_module+0x23b/0x650[ 19.477725] __x64_sys_finit_module+0xbe/0x130[ 19.476506] idempotent_init_module+0x23b/0x650[ 19.477725] __x64_sys_finit_module+0xbe/0x130[ 19.478920] do_syscall_64+0x82/0x160[ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 19.481292][ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512[ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200)[ 19.487447][ 19.488328] The buggy address belongs to the physical page:[ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60[ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0[ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)[ 19.493914] page_type: 0xffffffff()[ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001[ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000[ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001[ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000[ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff[ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000[ 19.503784] page dumped because: k---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49890 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: ensure the fw_info is not null before using itThis resolves the dereference null return value warningreported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49891 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata pathsWhen the HBA is undergoing a reset or is handling an errata event, NULL ptrdereference crashes may occur in routines such aslpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), orlpfc_abort_handler().Add NULL ptr checks before dereferencing hdwq pointers that may have beenfreed due to operations colliding with a reset or errata event handler.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49892 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Initialize get_bytes_per_element's default to 1Variables, used as denominators and maybe not assigned to other values,should not be 0. bytes_per_element_y & bytes_per_element_c areinitialized by get_bytes_per_element() which should never return 0.This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check stream before comparing them[WHAT & HOW]amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It isnecessary to check for null before dereferencing them.This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Initialize denominators' default to 1[WHAT & HOW]Variables used as denominators and maybe not assigned to other values,should not be 0. Change their default to 1 so they are never 0.This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrsThere are some cases, such as the one uncovered by Commit 46d4efcccc68("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")wheremsm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);is called on gpu->pdev == NULL, as the GPU device has not been fullyinitialized yet.Turns out that there's more than just the aforementioned path thatcauses this to happen (e.g. the case when there's speedbin data in thecatalog, but opp-supported-hw is missing in DT).Assigning msm_gpu->pdev earlier seems like the least painful solutionto this, therefore do so.Patchwork: https://patchwork.freedesktop.org/patch/602742/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)This commit adds a null check for the 'afb' variable in theamdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' wasassumed to be null, but was used later in the code without a null check.This could potentially lead to a null pointer dereference.Changes since v1:- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before using dc->clk_mgr[WHY & HOW]dc->clk_mgr is null checked previously in the same function, indicatingit might be null.Passing "dc" to "dc->hwss.apply_idle_power_optimizations", whichdereferences null "dc->clk_mgr". (The function pointer resolves to"dcn35_apply_idle_power_optimizations".)This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_funcThis commit adds a null check for the set_output_gamma function pointerin the dcn20_set_output_transfer_func function. Previously,set_output_gamma was being checked for null at line 1030, but then itwas being dereferenced without any null check at line 1048. This couldpotentially lead to a null pointer dereference error if set_output_gammais null.To fix this, we now ensure that set_output_gamma is not null beforedereferencing it. We do this by adding a null check for set_output_gammabefore the call to set_output_gamma at line 1048.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_streamThis commit addresses a null pointer dereference issue in the`commit_planes_for_stream` function at line 4140. The issue could occurwhen `top_pipe_to_program` is null.The fix adds a check to ensure `top_pipe_to_program` is not null beforeaccessing its stream_res. This prevents a null pointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue in the`dcn20_program_pipe` function. The issue could occur when`pipe_ctx->plane_state` is null.The fix adds a check to ensure `pipe_ctx->plane_state` is not nullbefore accessing. This prevents a null pointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hwThis commit addresses a potential null pointer dereference issue in the`dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or`dc->clk_mgr->funcs` is null.The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` isnot null before accessing its functions. This prevents a potential nullpointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before multiple uses[WHAT & HOW]Poniters, such as stream_enc and dc->bw_vbios, are null checked previouslyin the same function, so Coverity warns "implies that stream_enc anddc->bw_vbios might be null". They are used multiple times in thesubsequent code and need to be checked.This fixes 10 FORWARD_NULL issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49921 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before used[WHAT & HOW]Poniters, such as dc->clk_mgr, are null checked previously in the samefunction, so Coverity warns "implies that "dc->clk_mgr" might be null".As a result, these pointers need to be checked when used again.This fixes 10 FORWARD_NULL issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before using them[WHAT & HOW]These pointers are null checked previously in the same function,indicating they might be null as reported by Coverity. As a result,they need to be checked when used again.This fixes 3 FORWARD_NULL issue reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49923 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags[WHAT & HOW]"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus itcannot be a null pointer. Let's pass a valid pointer to avoid nulldereference.This fixes 2 FORWARD_NULL issues reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49929 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: avoid NULL pointer dereferenceiwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvstapointer is not NULL.It retrieves this pointer using iwl_mvm_sta_from_mac80211, which isdereferencing the ieee80211_sta pointer.If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULLpointer.Fix this by checking the sta pointer before retrieving the mvmstafrom it. If sta is not NULL, then mvmsta isn't either.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash> dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 : mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14]$66 = 0xffffffffcrash> px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash> sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash> px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49939 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: avoid to add interface to list twice when SERIf SER L2 occurs during the WoWLAN resume flow, the add interface flowis triggered by ieee80211_reconfig(). However, due tortw89_wow_resume() return failure, it will cause the add interface flowto be executed again, resulting in a double add list and causing a kernelpanic. Therefore, we have added a check to prevent double adding of thelist.list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.------------[ cut here ]------------kernel BUG at lib/list_debug.c:37!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021Workqueue: events_freezable ieee80211_restart_work [mac80211]RIP: 0010:__list_add_valid_or_report+0x5e/0xb0Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydevgsmi: Log Shutdown Reason 0x03---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_startIn sctp_listen_start() invoked by sctp_inet_listen(), it should set thesk_state back to CLOSED if sctp_autobind() fails due to whatever reason.Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuseis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash willbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hashis NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: do not assume bh is held in ppp_channel_bridge_input()Networking receive path is usually handled from BH handler.However, some protocols need to acquire the socket lock, andpackets might be stored in the socket backlog is the socket wasowned by a user process.In this case, release_sock(), __release_sock(), and sk_backlog_rcv()might call the sk->sk_backlog_rcv() handler in process context.sybot caught ppp was not considering this case inppp_channel_bridge_input() :WARNING: inconsistent lock state6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted--------------------------------inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304{SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK ***1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325stack backtrace:CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious 'GSO' packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49949 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ("net: be more gentle about silly gsorequests coming from user") virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: counttransport header in UFO") while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb->lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size);Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prevent nf_skb_duplicated corruptionsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could writeper-cpu variable nf_skb_duplicated in an unsafe way [1].Disabling preemption as hinted by the splat is not enough,we have to disable soft interrupts as well.[1]BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f4ce4f7def9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49954 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:static_call: Replace pointless WARN_ON() in static_call_module_notify()static_call_module_notify() triggers a WARN_ON(), when memory allocationfails in __static_call_add_module().That's not really justified, because the failure case must be correctlyhandled by the well known call chain and the error code is passedthrough to the initiating userspace application.A memory allocation fail is not a fatal problem, but the WARN_ON() takesthe machine out when panic_on_warn is set.Replace it with a pr_warn().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49955 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: battery: Fix possible crash when unregistering a battery hookWhen a battery hook returns an error when adding a new battery, thenthe battery hook is automatically unregistered.However the battery hook provider cannot know that, so it will latercall battery_hook_unregister() on the already unregistered batteryhook, resulting in a crash.Fix this by using the list head to mark already unregistered batteryhooks as already being unregistered so that they can be ignored bybattery_hook_unregister().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()->jbd2_cleanup_journal_tail()->__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()->lock_buffer(journal->j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded. Additionally, use journal instead ofosb->journal directly to simplify the code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: reserve space for inline xattr before attaching reflink treeOne of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting,the fsck -fn output showed the below corruption[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,but fsck believes the largest valid value is 227. Clamp the next record value? nThe stat output from the debugfs.ocfs2 showed the following corruptionwhere the "Next Free Rec:" had overshot the "Count:" in the root metadatablock. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... .......The issue was in the reflink workfow while reserving space for inlinexattr. The problematic function is ocfs2_reflink_xattr_inline(). By thetime this function is called the reflink tree is already recreated at thedestination inode from the source inode. At this point, this functionreserves space for inline xattrs at the destination inode without evenchecking if there is space at the root metadata block. It simply reducesthe l_count from 243 to 227 thereby making space of 256 bytes for inlinexattr whereas the inode already has extents beyond this index (in thiscase up to 230), thereby causing corruption.The fix for this is to reserve space for inline metadata at the destinationinode before the reflink tree gets recreated. The customer has verified thefix.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns errorIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()to recover some journal space. But if an error occurs while executingjbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for freespace right away, we try other branches, and if j_committing_transactionis NULL (i.e., the tid is 0), we will get the following complain:============================================JBD2: I/O error when updating journal superblock for sdd-8.__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available__jbd2_log_wait_for_space: no way to get more journal space in sdd-8------------[ cut here ]------------WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0Modules linked in:CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70[...]============================================So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing toclean up at the moment, continue to try to reclaim free space in other ways.Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corruptwhen updating journal superblock fails") to make jbd2_cleanup_journal_tailreturn the correct error code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49962 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49963 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: bcm2835: Fix timeout during suspend modeDuring noirq suspend phase the Raspberry Pi power driver suffer offirmware property timeouts. The reason is that the IRQ of the underlyingBCM2835 mailbox is disabled and rpi_firmware_property_list() will alwaysrun into a timeout [1].Since the VideoCore side isn't consider as a wakeup source, set theIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabledduring suspend-resume cycle.[1]PM: late suspend of devices complete after 1.754 msecsWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22cFirmware transaction 0x00028001 timeoutModules linked in:CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17Hardware name: BCM2835Call trace:unwind_backtrace from show_stack+0x18/0x1cshow_stack from dump_stack_lvl+0x34/0x44dump_stack_lvl from __warn+0x88/0xec__warn from warn_slowpath_fmt+0x7c/0xb0warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22crpi_firmware_property_list from rpi_firmware_property+0x68/0x8crpi_firmware_property from rpi_firmware_set_power+0x54/0xc0rpi_firmware_set_power from _genpd_power_off+0xe4/0x148_genpd_power_off from genpd_sync_power_off+0x7c/0x11cgenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0genpd_finish_suspend from dpm_run_callback+0x78/0xd0dpm_run_callback from device_suspend_noirq+0xc0/0x238device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5acsuspend_devices_and_enter from pm_suspend+0x254/0x2e4pm_suspend from state_store+0xa8/0xd4state_store from kernfs_fop_write_iter+0x154/0x1a0kernfs_fop_write_iter from vfs_write+0x12c/0x184vfs_write from ksys_write+0x78/0xc0ksys_write from ret_fast_syscall+0x0/0x54Exception stack(0xcc93dfa8 to 0xcc93dff0)[...]PM: noirq suspend of devices complete after 3095.584 msecs

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove unreasonable unlock in ocfs2_read_blocksPatch series "Misc fixes for ocfs2_read_blocks", v5.This series contains 2 fixes for ocfs2_read_blocks(). The first patch fixthe issue reported by syzbot, which detects bad unlock balance inocfs2_read_blocks(). The second patch fixes an issue reported by HemingZhao when reviewing above fix.This patch (of 2):There was a lock release before exiting, so remove the unreasonable unlock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49966 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: cancel dqi_sync_work before freeing oinfoocfs2_global_read_info() will initialize and schedule dqi_sync_work at theend, if error occurs after successfully reading global quota, it willtrigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16cThis reports that there is an active delayed work when freeing oinfo inerror handling, so cancel dqi_sync_work first. BTW, return status insteadof -1 when .read_file_info fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49967 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r8169: add tally counter fields added with RTL8125RTL8125 added fields to the tally counter, what may result in the chipdma'ing these new fields to unallocated memory. Therefore make surethat the allocated memory area is big enough to hold all of thetally counter values, even if we use only parts of it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: fix kernel info leak via "[uprobes]" vmaxol_add_vma() maps the uninitialized page allocated by __create_xol_area()into userspace. On some architectures (x86) this memory is readable evenwithout VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,although this doesn't really matter, debugger can read this memory anyway.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gso: fix udp gso fraglist segmentation after pull from frag_listDetect gso fraglist skbs with corrupted geometry (see below) andpass these to skb_segment instead of skb_segment_list, as the firstcan segment them correctly.Valid SKB_GSO_FRAGLIST skbs- consist of two or more segments- the head_skb holds the protocol headers plus first gso_size- one or more frag_list skbs hold exactly one segment- all but the last must be gso_sizeOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) canmodify these skbs, breaking these invariants.In extreme cases they pull all data into skb linear. For UDP, thiscauses a NULL ptr deref in __udpv4_gso_segment_list_csum atudp_hdr(seg->next)->dest.Detect invalid geometry due to pull, by checking head_skb size.Don't just drop, as this may blackhole a destination. Convert to beable to pass to regular skb_segment.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49983 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-freeWhen calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),the 'ppath' is updated but it is the 'path' that is freed, thus potentiallytriggering a double-free in the following process:ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!!So drop the unnecessary ppath and use path directly to avoid this problem.And use ext4_find_extent() directly to update path, avoiding unnecessarymemory allocation and freeing. Also, propagate the error returned byext4_find_extent() instead of using strange error codes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resumeIn case there is any sort of clock controller attached to this I2C buscontroller, for example Versaclock or even an AIC32x4 I2C codec, thenan I2C transfer triggered from the clock controller clk_ops .preparecallback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.This is because the clock controller first grabs the prepare_lock mutexand then performs the prepare operation, including its I2C access. TheI2C access resumes this I2C bus controller via .runtime_resume callback,which calls clk_prepare_enable(), which attempts to grab the prepare_lockmutex again and deadlocks.Since the clock are already prepared since probe() and unprepared inremove(), use simple clk_enable()/clk_disable() calls to enable anddisable the clock on runtime suspend and resume, to avoid hitting theprepare_lock mutex.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix integer overflow in BLKSECDISCARDI independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard()but for secure erase.Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r);will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix buffer overflow when parsing NFS reparse pointsReparseDataLength is sum of the InodeType size and DataBuffer size.So to get DataBuffer size it is needed to subtract InodeType's size fromReparseDataLength.Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBufferat position after the end of the buffer because it does not subtractInodeType size from the length. Fix this problem and correctly subtractvariable len.Member InodeType is present only when reparse buffer is large enough. Checkfor ReparseDataLength before accessing InodeType to prevent another invalidmemory access.Major and minor rdev values are present also only when reparse buffer islarge enough. Check for reparse buffer size before calling reparse_mkdev().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()In mlx5e_tir_builder_alloc() kvzalloc() may return NULLwhich is dereferenced on the next line in a referenceto the modify field.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix error path in multi-packet WQE transmitRemove the erroneous unmap in case no DMA mapping was establishedThe multi-packet WQE transmit code attempts to obtain a DMA mapping forthe skb. This could fail, e.g. under memory pressure, when the IOMMUdriver just can't allocate more memory for page tables. While the codetries to handle this in the path below the err_unmap label it erroneouslyunmaps one entry from the sq's FIFO list of active mappings. Since thecurrent map attempt failed this unmap is removing some random DMA mappingthat might still be required. If the PCI function now presents that IOVA,the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCIfunction in error state.The erroneous behavior was seen in a stress-test environment that createdmemory pressure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:static_call: Handle module init failure correctly in static_call_del_module()Module insertion invokes static_call_add_module() to initialize the staticcalls in a module. static_call_add_module() invokes __static_call_init(),which allocates a struct static_call_mod to either encapsulate the built-instatic call sites of the associated key into it so further modules can beadded or to append the module to the module chain.If that allocation fails the function returns with an error code and themodule core invokes static_call_del_module() to clean up eventually addedstatic_call_mod entries.This works correctly, when all keys used by the module were converted overto a module chain before the failure. If not then static_call_del_module()causes a #GP as it blindly assumes that key::mods points to a valid structstatic_call_mod.The problem is that key::mods is not a individual struct member of structstatic_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; };key::sites is a pointer to the list of built-in usage sites of the staticcall. The type of the pointer is differentiated by bit 0. A mods pointerhas the bit clear, the sites pointer has the bit set.As static_call_del_module() blidly assumes that the pointer is a validstatic_call_mod type, it fails to check for this failure case anddereferences the pointer to the list of built-in call sites, which isobviously bogus.Cure it by checking whether the key has a sites or a mods pointer.If it's a sites pointer then the key is not to be touched. As the sites arewalked in the same order as in __static_call_init() the site walk can beterminated because all subsequent sites have not been touched by the initcode due to the error exit.If it was converted before the allocation fail, then the inner loop whichsearches for a module match will find nothing.A fail in the second allocation in __static_call_init() is harmless anddoes not require special treatment. The first allocation succeeded andconverted the key to a module chain. That first entry has mod::mod == NULLand mod::next == NULL, so the inner loop of static_call_del_module() willneither find a module match nor a module chain. The next site in the walkwas either already converted, but can't match the module, or it will exitthe outer loop because it has a static_call_site pointer and not astatic_call_mod pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix memory leak in exfat_load_bitmap()If the first directory entry in the root directory is not a bitmapdirectory entry, 'bh' will not be released and reassigned, whichwill cause a memory leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix access to uninitialised lock in fc replay pathThe following kernel trace can be triggered with fstest generic/629 whenexecuted against a filesystem with fast-commit feature enabled:INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180...In the replay path there's an attempt to lock sbi->s_bdev_wb_lock infunction ext4_check_bdev_write_error(). Unfortunately, at this point thisspinlock has not been initialized yet. Moving it's initialization to anearlier point in __ext4_fill_super() fixes this splat.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: dax: fix overflowing extents beyond inode size when partially writingThe dax_iomap_rw() does two things in each iteration: map written blocksand copy user data to blocks. If the process is killed by user(See signalhandling in dax_iomap_iter()), the copied data will be returned and addedon inode size, which means that the length of written extents may exceedthe inode size, then fsck will fail. An example is given as:dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2Mfsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?Fix the problem by truncating extents if the written length is smallerthan expected.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kthread: unpark only parked kthreadCalling into kthread unparking unconditionally is mostly harmless whenthe kthread is already unparked. The wake up is then simply ignoredbecause the target is not in TASK_PARKED state.However if the kthread is per CPU, the wake up is preceded by a callto kthread_bind() which expects the task to be inactive and inTASK_PARKED state, which obviously isn't the case if it is unparked.As a result, calling kthread_stop() on an unparked per-cpu kthreadtriggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Fix this with skipping unecessary unparking while stopping a kthread.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix an unsafe loop on the listThe kernel may crash when deleting a genetlink family if there are stilllisteners for that family:Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace:__netlink_clear_multicast_users+0x74/0xc0genl_unregister_family+0xd4/0x2d0Change the unsafe loop on the list to a safe one, because inside theloop there is an element removal from this list.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50028 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: Reference count the zone in thermal_zone_get_by_id()There are places in the thermal netlink code where nothing preventsthe thermal zone object from going away while being accessed after ithas been returned by thermal_zone_get_by_id().To address this, make thermal_zone_get_by_id() get a reference on thethermal zone device object to be returned with the help of get_device(),under thermal_list_lock, and adjust all of its callers to this changewith the help of the cleanup.h infrastructure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:slip: make slhc_remember() more robust against malicious packetssyzbot found that slhc_remember() was missing checks againstmalicious packets [1].slhc_remember() only checked the size of the packet was at least 20,which is not good enough.We need to make sure the packet includes the IPv4 and TCP headerthat are supposed to be carried.Add iph and th pointers to make the code more readable.[1]BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50036 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: do not delay dst_entries_add() in dst_release()dst_entries_add() uses per-cpu data that might be freed at netnsdismantle from ip6_route_net_exit() calling dst_entries_destroy()Before ip6_route_net_exit() can be called, we release allthe dsts associated with this netns, via calls to dst_release(),which waits an rcu grace period before calling dst_destroy()dst_entries_add() use in dst_destroy() is racy, becausedst_entries_destroy() could have been called already.Decrementing the number of dsts must happen sooner.Notes:1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this.2) There is also discussion about removing this count of dst, which might happen in future kernels.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: avoid NFPROTO_UNSPEC where neededsyzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packetprocessing. As this is only useful to restrict locally terminatingTCP/UDP traffic, register this for ipv4 and ipv6 family only.Pablo points out that this is a general issue, direct users of theset/getsockopt interface can call into targets/matches that were onlyintended for use with ip(6)tables.Check all UNSPEC matches and targets for similar issues:- matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area.- targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE.Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, asthey are provided for use by ip(6)tables.The MARK target is also used by arptables, so register for NFPROTO_ARP too.While at it, bail out if connbytes fails to enable the correspondingconntrack family.This change passes the selftests in iptables.git.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50039 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: accept TCA_STAB only for root qdiscMost qdiscs maintain their backlog using qdisc_pkt_len(skb)on the assumption it is invariant between the enqueue()and dequeue() handlers.Unfortunately syzbot can crash a host rather easily usinga TBF + SFQ combination, with an STAB on SFQ [1]We can't support TCA_STAB on arbitrary level, this wouldrequire to maintain per-qdisc storage.[1][ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 88.798611] #PF: supervisor read access in kernel mode[ 88.799014] #PF: error_code(0x0000) - not-present page[ 88.799506] PGD 0 P4D 0[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00All code======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ...Code starting with the faulting instruction=========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ...[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0[ 88.808165] Call Trace:[ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix macvlan leak by synchronizing access to mac_filter_hashThis patch addresses a macvlan leak issue in the i40e driver caused byconcurrent access to vsi->mac_filter_hash. The leak occurs when multiplethreads attempt to modify the mac_filter_hash simultaneously, leading toinconsistent state and potential memory leaks.To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroingvf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),ensuring atomic operations and preventing concurrent access.Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) ini40e_add_mac_filter() to help catch similar issues in the future.Reproduction steps:1. Spawn VFs and configure port vlan on them.2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters).3. Observe the potential memory leak and inconsistent state in the mac_filter_hash.This synchronization ensures the integrity of the mac_filter_hash and preventsthe described leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_changerfcomm_sk_state_change attempts to use sock_lock so it must never becalled with it locked but rfcomm_sock_ioctl always attempt to lock itcausing the following trace:======================================================WARNING: possible circular locking dependency detected6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted------------------------------------------------------syz-executor386/5093 is trying to acquire lock:ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73but task is already holding lock:ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50045 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: br_netfilter: fix panic with metadata_dst skbFix a kernel panic in the br_netfilter module when sending untaggedtraffic via a VxLAN device.This happens during the check for fragmentation in br_nf_dev_queue_xmit.It is dependent on:1) the br_netfilter module being loaded;2) net.bridge.bridge-nf-call-iptables set to 1;3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;4) untagged frames with size higher than the VxLAN MTU forwarded/floodedWhen forwarding the untagged packet to the VxLAN bridge port, beforethe netfilter hooks are called, br_handle_egress_vlan_tunnel is called andchanges the skb_dst to the tunnel dst. The tunnel_dst is a metadata typeof dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a checkfor frames that needs to be fragmented: frames with higher MTU than theVxLAN device end up calling br_nf_ip_fragment, which in turns callip_skb_dst_mtu.The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dstwith valid dst->dev, thus the crash.This case was never supported in the first place, so drop the packetinstead.PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.[ 176.291791] Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000110[ 176.292101] Mem abort info:[ 176.292184] ESR = 0x0000000096000004[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits[ 176.292530] SET = 0, FnV = 0[ 176.292709] EA = 0, S1PTW = 0[ 176.292862] FSC = 0x04: level 0 translation fault[ 176.293013] Data abort info:[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000[ 176.294166] [0000000000000110] pgd=0000000000000000,p4d=0000000000000000[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel vethbr_netfilter bridge stp llc ipv6 crct10dif_ce[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted6.8.0-rc3-g5b3fbd61b9d1 #2[ 176.296314] Hardware name: linux,dummy-virt (DT)[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBSBTYPE=--)[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter][ 176.297636] sp : ffff800080003630[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:ffff6828c49ad9f8[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:00000000000003e8[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:ffff6828c3b16d28[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:0000000000000014[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:0000000095744632[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:ffffb7e137926a70[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :0000000000000000[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :f20e0100bebafeca[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :0000000000000000[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :ffff6828c7f918f0[ 176.300889] Call trace:[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter][ 176.301703] nf_hook_slow+0x48/0x124[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge][ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter][ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter][ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter][ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter][ 176.303359] nf_hook_slow+0x48/0x124[ 176.303---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()On the node of an NFS client, some files saved in the mountpoint of theNFS server were copied to another location of the same NFS server.Accidentally, the nfs42_complete_copies() got a NULL-pointer dereferencecrash with the following syslog:[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058[232066.588586] Mem abort info:[232066.588701] ESR = 0x0000000096000007[232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits[232066.589084] SET = 0, FnV = 0[232066.589216] EA = 0, S1PTW = 0[232066.589340] FSC = 0x07: level 3 translation fault[232066.589559] Data abort info:[232066.589683] ISV = 0, ISS = 0x00000007[232066.589842] CM = 0, WnR = 0[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000[232066.590757] Internal error: Oops: 96000007 [#1] SMP[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2[232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4][232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4][232066.598595] sp : ffff8000f568fc70[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6[232066.600498] x11: 00000000000000---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointer before dereferencing se[WHAT & HOW]se is null checked previously in the same function, indicatingit might be null; therefore, it must be checked when used again.This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver core: bus: Fix double free in driver API bus_register()For bus_register(), any error which happens after kset_register() willcause that @priv are freed twice, fixed by setting @priv with NULL afterthe first free.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: protect uart_port_dtr_rts() in uart_shutdown() tooCommit af224ca2df29 (serial: core: Prevent unsafe uart port access, part3) added few uport == NULL checks. It added one to uart_shutdown(), sothe commit assumes, uport can be NULL in there. But right after thatprotection, there is an unprotected "uart_port_dtr_rts(uport, false);"call. That is invoked only if HUPCL is set, so I assume that is thereason why we do not see lots of these reports.Or it cannot be NULL at this point at all for some reason :P.Until the above is investigated, stay on the safe side and move thisdereference to the if too.I got this inconsistency from Coverity under CID 1585130. Thanks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50061 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race ConditionIn the cdns_i3c_master_probe function, &master->hj_work is bound withcdns_i3c_master_hj. And cdns_i3c_master_interrupt can callcnds_i3c_master_demux_ibis function to start the work.If we remove the module which will call cdns_i3c_master_remove tomake cleanup, it will free master->base through i3c_master_unregisterwhile the work mentioned above will be used. The sequence of operationsthat may lead to a UAF bug is as follows:CPU0 CPU1 | cdns_i3c_master_hjcdns_i3c_master_remove |i3c_master_unregister(&master->base) |device_unregister(&master->dev) |device_release |//free master->base | | i3c_master_do_daa(&master->base) | //use master->baseFix it by ensuring that the work is canceled before proceeding withthe cleanup in cdns_i3c_master_remove.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs-srv: Avoid null pointer deref during path establishmentFor RTRS path establishment, RTRS client initiates and completes con_numof connections. After establishing all its connections, the informationis exchanged between the client and server through the info_req message.During this exchange, it is essential that all connections have beenestablished, and the state of the RTRS srv path is CONNECTED.So add these sanity checks, to make sure we detect and abort process inerror scenarios to avoid null pointer deref.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50067 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uprobe: avoid out-of-bounds memory access of fetching argsUprobe needs to fetch args into a percpu buffer, and then copy to ringbuffer to avoid non-atomic context problem.Sometimes user-space strings, arrays can be very large, but the size ofpercpu buffer is only page size. And store_trace_args() won't checkwhether these data exceeds a single page or not, caused out-of-boundsmemory access.It could be reproduced by following steps:1. build kernel with CONFIG_KASAN enabled2. save follow program as test.c```\#include \#include \#include // If string length large than MAX_STRING_SIZE, the fetch_store_strlen()// will return 0, cause __get_data_size() return shorter size, and// store_trace_args() will not trigger out-of-bounds access.// So make string length less than 4096.\#define STRLEN 4093void generate_string(char *str, int n){ int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0';}void print_string(char *str){ printf("%s\n", str);}int main(){ char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0;}```3. compile program`gcc -o test test.c`4. get the offset of `print_string()````objdump -t test | grep -w print_string0000000000401199 g F .text 000000000000001b print_string```5. configure uprobe with offset 0x1199```off=0x1199cd /sys/kernel/debug/tracing/echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_eventsecho 1 > events/uprobes/enableecho 1 > tracing_on```6. run `test`, and kasan will report error.==================================================================BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40RIP: 0033:0x401199Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ceRSP: 002b:00007ffdf00576a8 EFLAGS: 00000206RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 This commit enforces the buffer's maxlen less than a page-size to avoidstore_trace_args() out-of-memory access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:parport: Proper fix for array out-of-bounds accessThe recent fix for array out-of-bounds accesses replaced sprintf()calls blindly with snprintf(). However, since snprintf() returns thewould-be-printed size, not the actually output size, the lengthcalculation can still go over the given limit.Use scnprintf() instead of snprintf(), which returns the actuallyoutput letters, for addressing the potential out-of-bounds accessproperly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel: int340x: processor: Fix warning during module unloadThe processor_thermal driver uses pcim_device_enable() to enable a PCIdevice, which means the device will be automatically disabled on driverdetach. Thus there is no need to call pci_disable_device() again on it.With recent PCI device resource management improvements, e.g. commitf748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem isexposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]---Remove the excess pci_disable_device() calls.[ rjw: Subject and changelog edits ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mad: Improve handling of timed out WRs of mad agentCurrent timeout handler of mad agent acquires/releases mad_agent_privlock for every timed out WRs. This causes heavy locking contentionwhen higher no. of WRs are to be handled inside timeout handler.This leads to softlockup with below trace in some use cases whererdma-cm path is used to establish connection between peer nodesTrace:----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRsand invoke send handler post creating the list. The new method acquires/releases lock once to fetch the list and hence helps to reduce lockingcontetiong when processing higher no. of WRs

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy errorThe `nouveau_dmem_copy_one` function ensures that the copy push command issent to the device firmware but does not track whether it was executedsuccessfully.In the case of a copy error (e.g., firmware or hardware failure), thecopy push command will be sent via the firmware channel, and`nouveau_dmem_copy_one` will likely report success, leading to the`migrate_to_ram` function returning a dirty HIGH_USER page to the user.This can result in a security vulnerability, as a HIGH_USER page that maycontain sensitive or corrupted data could be returned to the user.To prevent this vulnerability, we allocate a zero page. Thus, in case ofan error, a non-dirty (zero) page will be returned to the user.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut downThere is a history of deadlock if reboot is performed at the beginningof booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFSshutdown, and at that time the audio driver was waiting onblk_mq_submit_bio() holding a mutex_lock while reading the fw binary.After that, a deadlock issue occurred while audio driver shutdown waswaiting for mutex_unlock of blk_mq_submit_bio(). To solve this, setSDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes downafter a UFS shutdown will return an error.[ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown][ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49][ 31.907806]I[0: swapper/0: 0] Call trace:[ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338[ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc[ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8[ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40[ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac[ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24[ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec[ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280[ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c[ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280[ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158[ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4[ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0[ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0[ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4[ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4[ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter][ 31.908783]I[0: swapper/0: 0] Call trace:[ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338[ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc[ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8[ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178[ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c[ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: probes: Remove broken LDR (literal) uprobe supportThe simulate_ldr_literal() and simulate_ldrsw_literal() functions areunsafe to use for uprobes. Both functions were originally written foruse with kprobes, and access memory with plain C accesses. When uprobeswas added, these were reused unmodified even though they cannot safelyaccess user memory.There are three key problems:1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()).2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN.3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers.Practically speaking, (1) and (2) are the big issues. Given there havebeen no reports of problems since the broken code was introduced, itappears that no-one is relying on probing these instructions withuprobes.Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW(literal), limiting the use of simulate_ldr_literal() andsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR(literal) and LDRSW (literal) will be rejected asarm_probe_decode_insn() will return INSN_REJECTED. In future we canconsider introducing working uprobes support for these instructions, butthis will require more significant work.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() couldpossibly return NULL pointer. NULL Pointer Dereference may betriggerred without addtional check.Add a NULL check for the returned pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix one more kernel-infoleak in algo dumpingDuring fuzz testing, the following issue was discovered:BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Bytes 328-379 of 732 are uninitializedMemory access of size 732 starts at ffff88800e18e000Data copied to user address 00007ff30f48aff0CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Fixes copying of xfrm algorithms where some randomdata of the structure fields can end up in userspace.Padding in structures may be filled with random (possibly sensitve)data and should never be given directly to user-space.A similar issue was resolved in the commit8222d5910dae ("xfrm: Zero padding when dumping algos and encap")Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Consider the NULL character when validating the event lengthstrlen() returns a string length excluding the null byte. If the stringlength equals to the maximum buffer length, the buffer will have nospace for the NULL terminating character.This commit checks this condition and returns failure for it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50151 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:be2net: fix potential memory leak in be_xmit()The be_xmit() returns NETDEV_TX_OK without freeing skbin case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50179 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: remove the incorrect Fw reference check when dirtying pagesWhen doing the direct-io reads it will also try to mark pages dirty,but for the read path it won't hold the Fw caps and there is casewill it get the Fw reference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:secretmem: disable memfd_secret() if arch cannot set direct mapReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). Thisis the case for example on some arm64 configurations, where marking 4kPTEs in the direct map not present can only be done if the direct map isset up at 4k granularity in the first place (as ARM's break-before-makesemantics do not easily allow breaking apart large/gigantic pages).More precisely, on arm64 systems with !can_set_direct_map(),set_direct_map_invalid_noflush() is a no-op, however it returns success(0) instead of an error. This means that memfd_secret will seemingly"work" (e.g. syscall succeeds, you can mmap the fd and fault in pages),but it does not actually achieve its goal of removing its memory from thedirect map.Note that with this patch, memfd_secret() will start erroring on systemswhere can_set_direct_map() returns false (arm64 withCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n andCONFIG_KFENCE=n), but that still seems better than the current silentfailure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', mostarm64 systems actually have a working memfd_secret() and aren't beaffected.From going through the iterations of the original memfd_secret patchseries, it seems that disabling the syscall in these scenarios was theintended behavior [1] (preferred over havingset_direct_map_invalid_noflush return an error as that would result inSIGBUSes at page-fault time), however the check for it got dropped betweenv16 [2] and v17 [3], when secretmem moved away from CMA allocations.[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: handle consistently DSS corruptionBugged peer implementation can send corrupted DSS options, consistentlyhitting a few warning in the data path. Use DEBUG_NET assertions, toavoid the splat on some builds and handle consistently the error, dumpingrelated MIBs and performing fallback and/or reset according to thesubflow type.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: explicitly clear the sk pointer, when pf->create failsWe have recently noticed the exact same KASAN splat as in commit6cd4a78d962b ("net: do not leave a dangling sk pointer, when socketcreation fails"). The problem is that commit did not fully address theproblem, as some pf->create implementations do not use sk_common_releasein their error paths.For example, we can use the same reproducer as in the above commit, butchanging ping to arping. arping uses AF_PACKET socket and if packet_createfails, it will just sk_free the allocated sk object.While we could chase all the pf->create implementations and make sure theyNULL the freed sk object on error from the socket, we can't guaranteefuture protocols will not make the same mistake.So it is easier to just explicitly NULL the sk pointer upon return frompf->create in __sock_create. We do know that pf->create always releases theallocated sk object on error, so if the pointer is not NULL, it isdefinitely dangling.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50187 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Stop the active perfmon before being destroyedUpon closing the file descriptor, the active performance monitor is notstopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,the active performance monitor's pointer (`vc4->active_perfmon`) is stillretained.If we open a new file descriptor and submit a few jobs with performancemonitors, the driver will attempt to stop the active performance monitorusing the stale pointer in `vc4->active_perfmon`. However, this pointeris no longer valid because the previous process has already terminated,and all performance monitors associated with it have been destroyed andfreed.To fix this, when the active performance monitor belongs to a givenprocess, explicitly stop it before destroying and freeing it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v4: Don't allow a VMOVP on a dying VPEKunkun Jiang reported that there is a small window of opportunity foruserspace to force a change of affinity for a VPE while the VPE has alreadybeen unmapped, but the corresponding doorbell interrupt still visible in/proc/irq/.Plug the race by checking the value of vmapp_count, which tracks whetherthe VPE is mapped ot not, and returning an error in this case.This involves making vmapp_count common to both GICv4.1 and its v4.0ancestor.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:posix-clock: Fix missing timespec64 check in pc_clock_settime()As Andrew pointed out, it will make sense that the PTP corechecked timespec64 struct's tv_sec and tv_nsec range before callingptp->info->settime64().As the man manual of clock_settime() said, if tp.tv_sec is negative ortp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,which include dynamic clocks which handles PTP clock, and the condition isconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()only check the timespec is valid, but not ensure that the time isin a valid range, so check it ahead using timespec64_valid_strict()in pc_clock_settime() and return -EINVAL if not valid.There are some drivers that use tp->tv_sec and tp->tv_nsec directly towrite registers without validity checks and assume that the higher layerhas checked it, which is dangerous and will benefit from this, such ashclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),and some drivers can remove the checks of itself.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50196 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: ocelot: fix system hang on level based interruptsThe current implementation only calls chained_irq_enter() andchained_irq_exit() if it detects pending interrupts.```for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc);```However, in case of GPIO pin configured in level mode and the parentcontroller configured in edge mode, GPIO interrupt might be lowered by thehardware. In the result, if the interrupt is short enough, the parentinterrupt is still pending while the GPIO interrupt is cleared;chained_irq_enter() never gets called and the system hangs trying toservice the parent interrupt.Moving chained_irq_enter() and chained_irq_exit() outside the for loopensures that they are called even when GPIO interrupt is lowered by thehardware.The similar code with chained_irq_enter() / chained_irq_exit() functionswrapping interrupt checking loop may be found in many other drivers:```grep -r -A 10 chained_irq_enter drivers/pinctrl```

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix encoder->possible_clonesInclude the encoder itself in its possible_clones bitmask.In the past nothing validated that drivers were populatingpossible_clones correctly, but that changed in commit74d2aacbe840 ("drm: Validate encoder->possible_clones").Looks like radeon never got the memo and is still notfollowing the rules 100% correctly.This results in some warnings during driver initialization:Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c...(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: propagate directory read errors from nilfs_find_entry()Syzbot reported that a task hang occurs in vcs_open() during a fuzzingtest for nilfs2.The root cause of this problem is that in nilfs_find_entry(), whichsearches for directory entries, ignores errors when loading a directorypage/folio via nilfs_get_folio() fails.If the filesystem images is corrupted, and the i_size of the directoryinode is large, and the directory page/folio is successfully read butfails the sanity check, for example when it is zero-filled,nilfs_check_folio() may continue to spit out error messages in bursts.Fix this issue by propagating the error to the callers when loading apage/folio fails in nilfs_find_entry().The current interface of nilfs_find_entry() and its callers is outdatedand cannot propagate error codes such as -EIO and -ENOMEM returned vianilfs_find_entry(), so fix it together.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: pass u64 to ocfs2_truncate_inline maybe overflowSyzbot reported a kernel BUG in ocfs2_truncate_inline. There are tworeasons for this: first, the parameter value passed is greater thanocfs2_max_inline_data_with_xattr, second, the start and end parameters ofocfs2_truncate_inline are "unsigned int".So, we need to add a sanity check for byte_start and byte_len right beforeocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greaterthan ocfs2_max_inline_data_with_xattr return -EINVAL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: do not pass a stopped vif to the driver in .get_txpowerAvoid potentially crashing in the driver because of uninitialized private data

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix crash when config small gso_max_size/gso_ipv4_max_sizeConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflowin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,because sk->sk_gso_max_size would be much bigger than device limits.Call Trace:tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs)Add check for the minimum value of gso_max_size and gso_ipv4_max_size.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50271 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:signal: restore the override_rlimit logicPrior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top ofucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class ofsignals. However now it's enforced unconditionally, even ifoverride_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGVsignal, sigqueue_alloc fails to allocate the necessary resources for thesignal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address andhandling the error. From the user-space perspective, applications areunaware that the limit has been reached and that the siginfo iseffectively 'corrupted'. This can lead to unpredictable behavior andcrashes, as we observed with java applications.Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skipthe comparison to max there if override_rlimit is set. This effectivelyrestores the old behavior.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reinitialize delayed ref list after deleting it from the listAt insert_delayed_ref() if we need to update the action of an existingref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head'sref_add_list using list_del(), which leaves the ref's add_list membernot reinitialized, as list_del() sets the next and prev members of thelist to LIST_POISON1 and LIST_POISON2, respectively.If later we end up calling drop_delayed_ref() against the ref, which canhappen during merging or when destroying delayed refs due to a transactionabort, we can trigger a crash since at drop_delayed_ref() we calllist_empty() against the ref's add_list, which returns false sincethe list was not reinitialized after the list_del() and as a consequencewe call list_del() again at drop_delayed_ref(). This results in aninvalid list access since the next and prev members are set to poisonpointers, resulting in a splat if CONFIG_LIST_HARDENED andCONFIG_DEBUG_LIST are set or invalid poison pointer dereferencesotherwise.So fix this by deleting from the list with list_del_init() instead.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: prevent the risk of a division by zeroAs reported by Coverity, the logic at tpg_precalculate_line()blindly rescales the buffer even when scaled_witdh is equal tozero. If this ever happens, this will cause a division by zero.Instead, add a WARN_ON_ONCE() to trigger such cases and returnwithout doing any precalculation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: av7110: fix a spectre vulnerabilityAs warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)There is a spectre-related vulnerability at the code. Fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50298 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: allocate vf_state during PF probesIn the previous implementation, vf_state is allocated memory only when VFis enabled. However, net_device_ops::ndo_set_vf_mac() may be called beforeVF is enabled to configure the MAC address of VF. If this is the case,enetc_pf_set_vf_mac() will access vf_state, resulting in access to a nullpointer. The simplified error log is as follows.root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89[ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004[ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy[ 173.641973] lr : do_setlink+0x4a8/0xec8[ 173.732292] Call trace:[ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80[ 173.738847] __rtnl_newlink+0x530/0x89c[ 173.742692] rtnl_newlink+0x50/0x7c[ 173.746189] rtnetlink_rcv_msg+0x128/0x390[ 173.750298] netlink_rcv_skb+0x60/0x130[ 173.754145] rtnetlink_rcv+0x18/0x24[ 173.757731] netlink_unicast+0x318/0x380[ 173.761665] netlink_sendmsg+0x17c/0x3c8

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-52332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-52559 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32values that come from the user via the submit_lookup_cmds() function.This addition could lead to an integer wrapping bug so use size_add()to prevent that.Patchwork: https://patchwork.freedesktop.org/patch/624696/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53050 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in hdcp2_get_capabilityAdd encoder check in intel_hdcp2_get_capability to avoidnull pointer error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in intel_hdcp_get_capabilitySometimes during hotplug scenario or suspend/resume scenario encoder isnot always initialized when intel_hdcp_get_capability adda check to avoid kernel null pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix 6 GHz scan constructionIf more than 255 colocated APs exist for the set of allAPs found during 2.4/5 GHz scanning, then the 6 GHz scanconstruction will loop forever since the loop variablehas type u8, which can never reach the number found whenthat's bigger than 255, and is stored in a u32 variable.Also move it into the loops to have a smaller scope.Using a u32 there is fine, we limit the number of APs inthe scan list and each has a limit on the number of RNRentries due to the frame size. With a limit of 1000 scanresults, a frame size upper bound of 4096 (really it'smore like ~2300) and a TBTT entry size of at least 11,we get an upper bound for the number of ~372k, well inthe bounds of a u32.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB dataIn case the non-paged data of a SKB carries protocol header and protocolpayload to be transmitted on a certain platform that the DMA AXI addresswidth is configured to 40-bit/48-bit, or the size of the non-paged datais bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXIaddress width is configured to 32-bit, then this SKB requires at leasttwo DMA transmit descriptors to serve it.For example, three descriptors are allocated to split one DMA buffermapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2].Then three elements of tx_q->tx_skbuff_dma[] will be allocated to holdextra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2].Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA bufferaddress returned by DMA mapping call. stmmac_tx_clean() will try tounmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].bufis a valid buffer address.The expected behavior that saves DMA buffer address of this non-pageddata to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL;On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by theDMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer addressobviously, then the DMA buffer will be unmapped immediately.There may be a rare case that the DMA engine does not finish thepending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will gohorribly wrong, DMA is going to access a unmapped/unreferenced memoryregion, corrupted data will be transmited or iommu fault will betriggered :(In contrast, the for-loop that maps SKB fragments behaves perfectlyas expected, and that is how the driver should do for both non-pageddata and paged frags actually.This patch corrects DMA map/unmap sequences by fixing the array indexfor tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.Tested and verified on DWXGMAC CORE 3.20a

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Fix KMSAN warning in decode_getfattr_attrs()Fix the following KMSAN warning:CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G BTainted: [B]=BAD_PAGEHardware name: QEMU Standard PC (Q35 + ICH9, 2009)==========================================================================================================BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe KMSAN warning is triggered in decode_getfattr_attrs(), when callingdecode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is notinitialized.Fix the issue by initializing fattr->mdsthreshold to NULL innfs_fattr_init().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix lock recursionafs_wake_up_async_call() can incur lock recursion. The problem is that itis called from AF_RXRPC whilst holding the ->notify_lock, but it tries totake a ref on the afs_call struct in order to pass it to a work queue - butif the afs_call is already queued, we then have an extraneous ref that mustbe put... calling afs_put_call() may call back down into AF_RXRPC throughrxrpc_kernel_shutdown_call(), however, which might try taking the->notify_lock again.This case isn't very common, however, so defer it to a workqueue. The oopslooks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: defer partition scanningWe need to suppress the partition scan from occuring within thecontroller's scan_work context. If a path error occurs here, the IO willwait until a path becomes available or all paths are torn down, but thataction also occurs within scan_work, so it would deadlock. Defer thepartion scan to a different context that does not block scan_work.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerWhen hvs is released, there is a possibility that vsk->trans may notbe initialized to NULL, which could lead to a dangling pointer.This issue is resolved by initializing vsk->trans to NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53112 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix NULL pointer dereference in alloc_pages_bulk_noprofWe triggered a NULL pointer dereference for ac.preferred_zoneref->zone inalloc_pages_bulk_noprof() when the task is migrated between cpusets.When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be¤t->mems_allowed. when first_zones_zonelist() is called to findpreferred_zoneref, the ac->nodemask may be modified concurrently if thetask is migrated between different cpusets. Assuming we have 2 NUMA Node,when traversing Node1 in ac->zonelist, the nodemask is 2, and whentraversing Node2 in ac->zonelist, the nodemask is 1. As a result, theac->preferred_zoneref points to NULL zone.In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds aallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leadingto NULL pointer dereference.__alloc_pages_noprof() fixes this issue by checking NULL pointer in commitea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") andcommit df76cee6bbeb ("mm, page_alloc: remove redundant checks from allocfastpath").To fix it, check NULL pointer for preferred_zoneref->zone.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53119 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio/vsock: Fix accept_queue memory leakAs the final stages of socket destruction may be delayed, it is possiblethat virtio_transport_recv_listen() will be called after the accept_queuehas been flushed, but before the SOCK_DONE flag has been set. As a result,sockets enqueued after the flush would remain unremoved, leading to amemory leak.vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK(!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) releaseclose_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound releaseIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() duringsocket destruction.unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: CT: Fix null-ptr-deref in add rule err flowIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()callback returns error, zone_rule->attr is used uninitiated. Fix it touse attr which has the needed pointer value.Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]... Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fs, lock FTE when checking if activeThe referenced commits introduced a two-step process for deleting FTEs:- Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE.- Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.However, this approach encounters a race condition if a rule with the samematch value is added simultaneously. In this scenario, fs_core may set thehardware deletion function to NULL prematurely, causing a panic duringsubsequent rule deletions.To prevent this, ensure the active flag of the FTE is checked under a lock,which will prevent the fs_core layer from attaching a new steering rule toan FTE that is in the process of deletion.[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func[ 438.968205] ------------[ cut here ]------------[ 438.968654] refcount_t: decrement hit 0; leaking memory.[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower][ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 438.986507] Call Trace:[ 438.986799] [ 438.987070] ? __warn+0x7d/0x110[ 438.987426] ? refcount_warn_saturate+0xfb/0x110[ 438.987877] ? report_bug+0x17d/0x190[ 438.988261] ? prb_read_valid+0x17/0x20[ 438.988659] ? handle_bug+0x53/0x90[ 438.989054] ? exc_invalid_op+0x14/0x70[ 438.989458] ? asm_exc_invalid_op+0x16/0x20[ 438.989883] ? refcount_warn_saturate+0xfb/0x110[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core][ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core][ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core][ 438.992054] ? xas_load+0x9/0xb0[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core][ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core][ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core][ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core][ 438.994728] tc_setup_cb_destroy+0xb9/0x190[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower][ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower][ 438.996105] tc_new_tfilter+0x347/0xbc0[ 438.996503] ? __---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: cope racing subflow creation in mptcp_rcv_space_adjustAdditional active subflows - i.e. created by the in kernel pathmanager - are included into the subflow list before starting the3whs.A racing recvmsg() spooling data received on an already establishedsubflow would unconditionally call tcp_cleanup_rbuf() on all thecurrent subflows, potentially hitting a divide by zero error onthe newly created ones.Explicitly check that the subflow is in a suitable state beforeinvoking tcp_cleanup_rbuf().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53129 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop: Fix a dereferenced before check warningThe 'state' can't be NULL, we should check crtc_state.Fix warning:drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096vop_plane_atomic_async_check() warn: variable dereferenced before check'state' (see line 1077)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53130 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_dirty_buffer tracepointWhen using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()may cause a NULL pointer dereference, or a general protection fault whenKASAN is enabled.This happens because, since the tracepoint was added inmark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_devregardless of whether the buffer head has a pointer to a block_devicestructure.In the current implementation, nilfs_grab_buffer(), which grabs a bufferto read (or create) a block of metadata, including b-tree node blocks,does not set the block device, but instead does so only if the buffer isnot in the "uptodate" state for each of its caller block readingfunctions. However, if the uptodate flag is set on a folio/page, and thebuffer heads are detached from it by try_to_free_buffers(), and new bufferheads are then attached by create_empty_buffers(), the uptodate flag maybe restored to each buffer without the block device being set tobh->b_bdev, and mark_buffer_dirty() may be called later in that state,resulting in the bug mentioned above.Fix this issue by making nilfs_grab_buffer() always set the block deviceof the super block structure to the buffer head, regardless of the stateof the buffer's uptodate flag.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_touch_buffer tracepointPatch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".This series fixes null pointer dereference bugs that occur when usingnilfs2 and two block-related tracepoints.This patch (of 2):It has been reported that when using "block:block_touch_buffer"tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes aNULL pointer dereference, or a general protection fault when KASAN isenabled.This happens because since the tracepoint was added in touch_buffer(), itreferences the dev_t member bh->b_bdev->bd_dev regardless of whether thebuffer head has a pointer to a block_device structure. In the currentimplementation, the block_device structure is set after the functionreturns to the caller.Here, touch_buffer() is used to mark the folio/page that owns the bufferhead as accessed, but the common search helper for folio/page used by thecaller function was optimized to mark the folio/page as accessed when itwas reimplemented a long time ago, eliminating the need to calltouch_buffer() here in the first place.So this solves the issue by eliminating the touch_buffer() call itself.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53140 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: fastmap: Fix duplicate slab cache names while attachingSince commit 4c39529663b9 ("slab: Warn on duplicate cache names whenDEBUG_VM=y"), the duplicate slab cache names can be detected and akernel WARNING is thrown out.In UBI fast attaching process, alloc_ai() could be invoked twicewith the same slab cache name 'ubi_aeb_slab_cache', which will triggerfollowing warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0The problem could be easily reproduced by loading UBI device by fastmapwith CONFIG_DEBUG_VM=y.Fix it by using different slab names for alloc_ai() callers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: make sure cache entry active before cache_showThe function `c_show` was called with protection from RCU. This onlyensures that `cp` will not be freed. Therefore, the reference count for`cp` can drop to zero, which will trigger a refcount use-after-freewarning when `cache_get` is called. To resolve this issue, use`cache_get_rcu` to ensure that `cp` remains active.------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 7 PID: 822 at lib/refcount.c:25refcount_warn_saturate+0xb1/0x120CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb1/0x120Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Add sanity NULL check for the default mmap fault handlerA driver might allow the mmap access before initializing itsruntime->dma_area properly. Add a proper NULL check before passing tovirt_to_page() for avoiding a panic.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53183 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: net: Do not use drvdata in releaseThe drvdata is not available in release. Let's just use container_of()to get the uml_net instance. Otherwise, removing a network device willresult in a crash:RIP: 0033:net_device_release+0x10/0x6fRSP: 00000000e20c7c40 EFLAGS: 00010206RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6Kernel panic - not syncing: Segfault with no mmCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1Workqueue: events mc_work_procStack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: ubd: Do not use drvdata in releaseThe drvdata is not available in release. Let's just use container_of()to get the ubd instance. Otherwise, removing a ubd device will resultin a crash:RIP: 0033:blk_mq_free_tag_set+0x1f/0xbaRSP: 00000000e2083bf0 EFLAGS: 00010246RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0Kernel panic - not syncing: Segfault with no mmCPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1Workqueue: events mc_work_procStack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0Call Trace: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] device_release+0x70/0xba [<60381d6a>] kobject_put+0xb5/0xe2 [<6026027b>] put_device+0x19/0x1c [<6026a036>] platform_device_put+0x26/0x29 [<6026ac5a>] platform_device_unregister+0x2c/0x2e [<6002c52e>] ubd_remove+0xb8/0xd6 [<6002bb74>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? mconsole_reply+0x48/0x50 [<6003379c>] ? um_set_signals+0x3b/0x43 [<60061c55>] ? update_min_vruntime+0x14/0x70 [<6006251f>] ? dequeue_task_fair+0x164/0x235 [<600620aa>] ? update_cfs_group+0x0/0x40 [<603a0e77>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] process_scheduled_works+0x1af/0x2c3 [<6004ede3>] ? assign_work+0x0/0x58 [<600527a1>] worker_thread+0x2f7/0x37a [<6004ee3b>] ? set_pf_worker+0x0/0x64 [<6005765d>] ? arch_local_irq_save+0x0/0x2d [<60058e07>] ? kthread_exit+0x0/0x3a [<600524aa>] ? worker_thread+0x0/0x37a [<60058f9f>] kthread+0x130/0x135 [<6002068e>] new_thread_handler+0x85/0xb6

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53210 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()There's issue as follows:RPC: Registered rdma transport module.RPC: Registered rdma backchannel transport module.RPC: Unregistered rdma transport module.RPC: Unregistered rdma backchannel transport module.BUG: unable to handle page fault for address: fffffbfff80c609aPGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTIRIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0Call Trace: __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will notdestroy the percpu counters which init in svc_rdma_proc_init().If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the'percpu_counters' list. The above issue may occur once the module isremoved. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memoryleakage occurs.To solve above issue just destroy all percpu counters whenregister_sysctl() return NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent NULL dereference in nfsd4_process_cb_update()@ses is initialized to NULL. If __nfsd4_find_backchannel() finds noavailable backchannel session, setup_callback_client() will try todereference @ses and segfault.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to account dirty data in __get_secs_required()It will trigger system panic w/ testcase in [1]:------------[ cut here ]------------kernel BUG at fs/f2fs/segment.c:2752!RIP: 0010:new_curseg+0xc81/0x2110Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe root cause is if checkpoint_disabling and lfs_mode are both on,it will trigger OPU for all overwritten data, it may cost more freesegment than expected, so f2fs must account those data correctly tocalculate cosumed free segments later, and return ENOSPC earlier toavoid run out of free segment during block allocation.[1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-54458 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: bsg: Set bsg_queue to NULL after removalCurrently, this does not cause any issues, but I believe it is necessary toset bsg_queue to NULL after removing it to prevent potential use-after-free(UAF) access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-55881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Play nice with protected guests in complete_hypercall_exit()Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bithypercall when completing said hypercall. For guests with protected state,e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bitmode as the vCPU state needed to detect 64-bit mode is unavailable.Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGEhypercall via VMGEXIT trips the WARN: ------------[ cut here ]------------ WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm] Modules linked in: kvm_amd kvm ... [last unloaded: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470 Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024 RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm] kvm_vcpu_ioctl+0x54f/0x630 [kvm] __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56538 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_kms: Unplug DRM device before removalPrevent userspace accesses to the DRM device from causinguse-after-frees by unplugging the device before we remove it. Thiscauses any further userspace accesses to result in an error withoutfurther calls into this driver's internals.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56562 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr"Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56567 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ad7780: fix division by zero in ad7780_write_raw()In the ad7780_write_raw() , val2 can be zero, which might lead to adivision by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()is based on iio_info's write_raw. While val is explicitly declared thatcan be zero (in read mode), val2 is not specified to be non-zero.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56575 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Ensure power suppliers be suspended before detach themThe power suppliers are always requested to suspend asynchronously,dev_pm_domain_detach() requires the caller to ensure propersynchronization of this function with power management callbacks.otherwise the detach may led to kernel panic, like below:[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[ 1457.116777] Mem abort info:[ 1457.119589] ESR = 0x0000000096000004[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits[ 1457.128692] SET = 0, FnV = 0[ 1457.131764] EA = 0, S1PTW = 0[ 1457.134920] FSC = 0x04: level 0 translation fault[ 1457.139812] Data abort info:[ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec][ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)[ 1457.199236] Workqueue: pm pm_runtime_work[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290[ 1457.214886] lr : __rpm_callback+0x48/0x1d8[ 1457.218968] sp : ffff80008250bc50[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000[ 1457.293510] Call trace:[ 1457.295946] genpd_runtime_suspend+0x20/0x290[ 1457.300296] __rpm_callback+0x48/0x1d8[ 1457.304038] rpm_callback+0x6c/0x78[ 1457.307515] rpm_suspend+0x10c/0x570[ 1457.311077] pm_runtime_work+0xc4/0xc8[ 1457.314813] process_one_work+0x138/0x248[ 1457.318816] worker_thread+0x320/0x438[ 1457.322552] kthread+0x110/0x114[ 1457.325767] ret_from_fork+0x10/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix crash in the probe error path when using pollingIf an error occurs in the probe() function, we should remove the pollingtimer that was alarmed earlier, otherwise the timer is called witharguments that are already freed, which results in a crash.------------[ cut here ]------------WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268Modules linked in:CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226Hardware name: Diasom DS-RK3568-SOM-EVB (DT)pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __run_timers+0x244/0x268lr : __run_timers+0x1d4/0x268sp : ffffff80eff2baf0x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffffx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003ex14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56578 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Set video drvdata before register video deviceThe video drvdata should be set before the video device is registered,otherwise video_drvdata() may return NULL in the open() file ops, and ledto oops.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ref-verify: fix use-after-free after invalid ref actionAt btrfs_ref_tree_mod() after we successfully inserted the new ref entry(local variable 'ref') into the respective block entry's rbtree (localvariable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,we error out and free the ref entry without removing it from the blockentry's rbtree. Then in the error path of btrfs_ref_tree_mod() we callbtrfs_free_ref_cache(), which iterates over all block entries and thencalls free_block_entry() for each one, and there we will trigger ause-after-free when we are called against the block entry to which weadded the freed ref entry to its rbtree, since the rbtree still pointsto the block entry, as we didn't remove it from the rbtree before freeingit in the error path at btrfs_ref_tree_mod(). Fix this by removing thenew ref entry from the rbtree before freeing it.Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56583 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix warning in migrate_enable for boosted tasksWhen running the following command:while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quietdonea warning is eventually triggered:WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794setup_new_dl_entity+0x13e/0x180...Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92bThis warning occurs because set_cpus_allowed dequeues and enqueues taskswith the ENQUEUE_RESTORE flag set. If the task is boosted, the warningis triggered. A boosted task already had its parameters set byrt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,hence the WARN_ON call.Check if we are requeueing a boosted task and avoid callingsetup_new_dl_entity if that's the case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56584 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/tctx: work around xa_store() allocation error issuesyzbot triggered the following WARN_ON:WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51which is theWARN_ON_ONCE(!xa_empty(&tctx->xa));sanity check in __io_uring_free() when a io_uring_task is going throughits final put. The syzbot test case includes injecting memory allocationfailures, and it very much looks like xa_store() can fail one of itsmemory allocations and end up with ->head being non-NULL even though noentries exist in the xarray.Until this issue gets sorted out, work around it by attempting toiterate entries in our xarray, and WARN_ON_ONCE() if one is found.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Add cond_resched() for no forced preemption modelFor no forced preemption model kernel, in the scenario where theexpander is connected to 12 high performance SAS SSDs, the followingcall trace may occur:[ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211][ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)[ 214.575224][ C240] pc : fput_many+0x8c/0xdc[ 214.579480][ C240] lr : fput+0x1c/0xf0[ 214.583302][ C240] sp : ffff80002de2b900[ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000[ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000[ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000[ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001[ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000[ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000[ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0[ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff[ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c[ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0[ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001[ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080[ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554[ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020[ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8[ 214.677191][ C240] Call trace:[ 214.680320][ C240] fput_many+0x8c/0xdc[ 214.684230][ C240] fput+0x1c/0xf0[ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc[ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140[ 214.696917][ C240] bio_endio+0x160/0x1bc[ 214.701001][ C240] blk_update_request+0x1c8/0x3bc[ 214.705867][ C240] scsi_end_request+0x3c/0x1f0[ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0[ 214.715249][ C240] scsi_finish_command+0x104/0x140[ 214.720200][ C240] scsi_softirq_done+0x90/0x180[ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70[ 214.730016][ C240] scsi_mq_done+0x48/0xac[ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas][ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw][ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw][ 214.752179][ C240] irq_thread_fn+0x34/0xa4[ 214.756435][ C240] irq_thread+0xc4/0x130[ 214.760520][ C240] kthread+0x108/0x13c[ 214.764430][ C240] ret_from_fork+0x10/0x18This is because in the hisi_sas driver, both the hardware interrupthandler and the interrupt thread are executed on the same CPU. In theperformance test scenario, function irq_wait_for_interrupt() will alwaysreturn 0 if lots of interrupts occurs and the CPU will be continuouslyconsumed. As a result, the CPU cannot run the watchdog thread. When thewatchdog time exceeds the specified time, call trace occurs.To fix it, add cond_resched() to execute the watchdog thread.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56592 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab's lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock's type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn't support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn't have the problem, so keptit as---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56593 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56595 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add a check to prevent array-index-out-of-bounds in dbAdjTreeWhen the value of lp is 0 at the beginning of the for loop, it willbecome negative in the next assignment and we should bail out.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56596 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in jfs_readdirThe stbl might contain some invalid values. Added a check toreturn error code in that case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56603 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56611 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn'ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56614 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says:"In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption."It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] [76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56616 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: sysfs: Prevent div by zeroPrevent a division by 0 when monitoring is not enabled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56629 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix when get product name maybe null pointerDue to incorrect dev->product reporting by certain devices, nullpointer dereferences occur when dev->product is empty, leading topotential system crashes.This issue was found on EXCELSIOR DL37-D05 device withLoongson-LS3A6000-7A2000-DL37 motherboard.Kernel logs:[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci[ 56.671638] usb 4-3: string descriptor 0 read error: -22[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07[ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0[ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80[ 56.697732] Oops[#1]:[ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015[ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024[ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0[ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000[ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000[ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005[ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000[ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028[ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000[ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000[ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom][ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120[ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)[ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)[ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)[ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)[ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)[ 56.697835] BADV: 0000000000000000[ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)[ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit[ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)[ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000[ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000[ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0[ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c[ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440[ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0[ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c[ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000[ 56.697931] 90000001000bb8d0 ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56630 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: grgpio: Add NULL check in grgpio_probedevm_kasprintf() can return a NULL pointer on failure,but thisreturned value in grgpio_probe is not checked.Add NULL check in grgpio_probe, to handle kernel NULLpointer dereference error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56641 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56647 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56657 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: control: Avoid WARN() for symlink errorsUsing WARN() for showing the error of symlink creations don't givemore information than telling that something goes wrong, since theusual code path is a lregister callback from each control elementcreation. More badly, the use of WARN() rather confuses fuzzer as ifit were serious issues.This patch downgrades the warning messages to use the normal dev_err()instead of WARN(). For making it clearer, add the function name tothe prefix, too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapb: increase LAPB_HEADER_LENIt is unclear if net/lapb code is supposed to be ready for 8021q.We can at least avoid crashes like the following :skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, prevent potential error pointer dereferenceThe dr_domain_add_vport_cap() function generally returns NULL on errorbut sometimes we want it to return ERR_PTR(-EBUSY) so the caller canretry. The problem here is that "ret" can be either -EBUSY or -ENOMEMand if it's and -ENOMEM then the error pointer is propogated back andeventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56688 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56698 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Fix looping of queued SG entriesThe dwc3_request->num_queued_sgs is decremented on completion. If apartially completed request is handled, then thedwc3_request->num_queued_sgs no longer reflects the total number ofnum_queued_sgs (it would be cleared).Correctly check the number of request SG entries remained to be prepareand queued. Failure to do this may cause null pointer dereference whenaccessing non-existent SG entry.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56701 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix dtl_access_lock to be a rw_semaphoreThe dtl_access_lock needs to be a rw_sempahore, a sleeping lock, becausethe code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatch_stats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dump_stack_lvl+0x130/0x148 (unreliable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 system_call_exception+0x1c4/0x5a0 system_call_common+0xf4/0x258

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.cAdd error pointer checks after calling otx2_mbox_get_rsp().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if iowq is killed before queuingtask work can be executed after the task has gone through io_uringtermination, whether it's the final task_work run or the fallback path.In this case, task work will find ->io_wq being already killed andnull'ed, which is a problem if it then tries to forward the request toio_queue_iowq(). Make io_queue_iowq() fail requests in this case.Note that it also checks PF_KTHREAD, because the user can first closea DEFER_TASKRUN ring and shortly after kill the task, in which case->iowq check would race.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: Fix netdev notifier unregister on failureIf register_netdev() fails, then the driver leaks the netdev notifier.Fix this by calling ionic_lif_unregister() on register_netdev()failure. This will also call ionic_lif_unregister_phc() if it hasalready been registered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56716 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: prevent bad user input in nsim_dev_health_break_write()If either a zero count or a large one is provided, kernel can crash.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56720 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Several fixes to bpf_msg_pop_dataSeveral fixes to bpf_msg_pop_data,1. In sk_msg_shift_left, we should put_page2. if (len == 0), return early is better3. pop the entire sk_msg (last == msg->sg.size) should be supported4. Fix for the value of variable "a"5. In sk_msg_shift_left, after shifting, i has already pointed to the nextelement. Addtional sk_msg_iter_var_next may result in BUG.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix cpu stuck caused by printings during resetDuring reset, cmd to destroy resources such as qp, cq, and mr may fail,and error logs will be printed. When a large number of resources aredestroyed, there will be lots of printings, and it may lead to a cpustuck.Delete some unnecessary printings and replace other printing functionsin these paths with the ratelimited version.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devicesWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56726 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.cAdding error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56739 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtc: check if __rtc_read_time was successful in rtc_timer_do_work()If the __rtc_read_time call fails,, the struct rtc_time tm; may containuninitialized data, or an illegal date/time read from the RTC hardware.When calling rtc_tm_to_ktime later, the result may be a very large value(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,they will continually expire, may causing kernel softlockup.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reset_method_store() memory leakIn reset_method_store(), a string is allocated via kstrndup() and assignedto the local "options". options is then used in with strsep() to findspaces: while ((name = strsep(&options, " ")) != NULL) {If there are no remaining spaces, then options is set to NULL by strsep(),so the subsequent kfree(options) doesn't free the memory allocated viakstrndup().Fix by using a separate tmp_options to iterate with strsep() so options ispreserved.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56774 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add a sanity check for btrfs root in btrfs_search_slot()Syzbot reports a null-ptr-deref in btrfs_search_slot().The reproducer is using rescue=ibadroots, and the extent tree root iscorrupted thus the extent tree is NULL.When scrub tries to search the extent tree to gather the needed extentinfo, btrfs_search_slot() doesn't check if the target root is NULL ornot, resulting the null-ptr-deref.Add sanity check for btrfs root before using it in btrfs_search_slot().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointersThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_checkThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56778 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_checkThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: imx8m: Probe the SoC driver as platform driverWith driver_async_probe=* on kernel command line, the following trace isproduced because on i.MX8M Plus hardware because the soc-imx8m.c drivercalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clockdriver is not yet probed. This was not detected during regular testingwithout driver_async_probe.Convert the SoC code to platform driver and instantiate a platform devicein its current device_initcall() to probe the platform driver. Rework.soc_revision callback to always return valid error code and return SoCrevision via parameter. This way, if anything in the .soc_revision callbackreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will getretried later."------------[ cut here ]------------WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : imx8mm_soc_revision+0xdc/0x180lr : imx8mm_soc_revision+0xd0/0x180sp : ffff8000821fbcc0x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfbx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95cx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfbCall trace: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---SoC: i.MX8MP revision 1.1"

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix for a potential deadlockThis fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);Fix this by temporarily releasing the reset_mutex.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: imx6: Fix suspend/resume support on i.MX6QDLThe suspend/resume functionality is currently broken on the i.MX6QDLplatform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdfThis patch addresses the issue by sharing most of the suspend/resumesequences used by other i.MX devices, while avoiding modifications tocritical registers that disrupt the PCIe functionality. It targets thesame problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995Unlike the downstream commit, this patch also resets the connected PCIedevice if possible. Without this reset, certain drivers, such as ath10kor iwlwifi, will crash on resume. The device reset is also done by thedriver on other i.MX platforms, making this patch consistent withexisting practices.Upon resuming, the kernel will hang and display an error. Here's anexample of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944Without this patch, suspend/resume will fail on i.MX6QDL devices if aPCIe device is connected.[kwilczynski: commit log, added tag for stable releases]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_threadsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]If dvb->mux is not initialized successfully by vidtv_mux_init() in thevidtv_start_streaming(), it will trigger null pointer dereference about muxin vidtv_mux_stop_thread().Adjust the timing of streaming initialization and check it beforestopping it.[1]KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM workerAfter commit746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720... [ ] The intent of the verifcation done in check_flush_depedency is to ensureforward progress during memory reclaim, by flagging cases when either amemory reclaim process, or a memory reclaim work item is flushed from acontext not marked as memory reclaim safe.This is correct when flushing, but when called from thecancel(_delayed)_work_sync() paths it is a false positive because work iseither already running, or will not be running at all. Thereforecancelling it is safe and we can relax the warning criteria by letting thehelper know of the calling context.References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57889 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap lockingIf a device uses MCP23xxx IO expander to receive IRQs, the followingbug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...We observed the problem while experimenting with a touchscreen driver whichused MCP23017 IO expander (I2C).The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection fromconcurrent accesses, which is the default for regmaps without .fast_io,.disable_locking, etc.mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latterlocks the mutex.However, __setup_irq() locks desc->lock spinlock before calling thesefunctions. As a result, the system tries to lock the mutex whole holdingthe spinlock.It seems, the internal regmap locks are not needed in this driver at all.mcp->lock seems to protect the regmap from concurrent accesses already,except, probably, in mcp_pinconf_get/set.mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called underchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takesmcp->lock and enables regmap caching, so that the potentially slow I2Caccesses are deferred until chip_bus_unlock().The accesses to the regmap from mcp23s08_probe_one() do not need additionallocking.In all remaining places where the regmap is accessed, exceptmcp_pinconf_get/set(), the driver already takes mcp->lock.This patch adds locking in mcp_pinconf_get/set() and disables internallocking in the regmap config. Among other things, it fixes the sleepingin atomic context described above.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57892 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed. Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: flush delalloc workers queue before stopping cleaner kthread during unmountDuring the unmount path, at close_ctree(), we first stop the cleanerkthread, using kthread_stop() which frees the associated task_struct, andthen stop and destroy all the work queues. However after we stopped thecleaner we may still have a worker from the delalloc_workers queue runninginode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),which in turn tries to wake up the cleaner kthread - which was alreadydestroyed before, resulting in a use-after-free on the task_struct.Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57903 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57924 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57932 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57933 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XSK operations on the existence of queuesThis patch predicates the enabling and disabling of XSK pools on theexistence of queues. As it stands, if the interface is down, disablingor enabling XSK pools would result in a crash, as the RX queue pointerwould be NULL. XSK pool registration will occur as part of the nextinterface up.Similarly, xsk_wakeup needs be guarded against queues disappearingwhile the function is executing, so a check against theGVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with thedisabling of the bit and the synchronize_net() in gve_turndown.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57938 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rdma/cxgb4: Prevent potential integer overflow on 32bitThe "gl->tot_len" variable is controlled by the user. It comes fromprocess_responses(). On 32bit systems, the "gl->tot_len + sizeof(structcpl_pass_accept_req) + sizeof(struct rss_header)" addition could have aninteger wrapping bug. Use size_add() to prevent this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57974 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Deal with race between UDP socket address change and rehashIf a UDP socket changes its local address while it's receivingdatagrams, as a result of connect(), there is a period during whicha lookup operation might fail to find it, after the address is changedbut before the secondary hash (port and address) and the four-tuplehash (local and remote ports and addresses) are updated.Secondary hash chains were introduced by commit 30fff9231fad ("udp:bind() optimisation") and, as a result, a rehash operation becameneeded to make a bound socket reachable again after a connect().This operation was introduced by commit 719f835853a9 ("udp: addrehash on connect()") which isn't however a complete fix: thesocket will be found once the rehashing completes, but not whileit's pending.This is noticeable with a socat(1) server in UDP4-LISTEN mode, and aclient sending datagrams to it. After the server receives the firstdatagram (cf. _xioopen_ipdgram_listen()), it issues a connect() tothe address of the sender, in order to set up a directed flow.Now, if the client, running on a different CPU thread, happens tosend a (subsequent) datagram while the server's socket changes itsaddress, but is not rehashed yet, this will result in a failedlookup and a port unreachable error delivered to the client, asapparent from the following reproducer: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait donewhere the client will eventually get ECONNREFUSED on a write()(typically the second or third one of a given iteration): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refusedThis issue was first observed as a seldom failure in Podman's testschecking UDP functionality while using pasta(1) to connect thecontainer's network namespace, which leads us to a reproducer withthe lookup error resulting in an ICMP packet on a tap device: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out doneOnce this fails: tmp.in tmp.out differ: char 8193, line 29we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0On the third datagram received, the network namespace of the containerinitiates an ARP lookup to deliver the ICMP message.In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pps: Fix a use-after-freeOn a board running ntpd and gpsd, I'm seeing a consistent use-after-freein sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]---...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exceptionThis happens because pps_device_destruct() frees the pps_device with theembedded cdev immediately after calling cdev_del(), but, as the commentabove cdev_del() notes, fops for previously opened cdevs are stillcallable even after cdev_del() returns. I think this bug has alwaysbeen there: I can't explain why it suddenly started happening every timeI reboot this particular board.In commit d953e0e837e6 ("pps: Fix a use-after free bug whenunregistering a source."), George Spelvin suggested removing theembedded cdev. That seems like the simplest way to fix this, so I'veimplemented his suggestion, using __register_chrdev() with pps_idrbecoming the source of truth for which minor corresponds to whichdevice.But now that pps_idr defines userspace visibility instead of cdev_add(),we need to be sure the pps->dev refcount can't reach zero whileuserspace can still find it again. So, the idr_remove() call moves topps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix double free in error pathIf the uvc_status_init() function fails to allocate the int_urb, it willfree the dev->status pointer but doesn't reset the pointer to NULL. Thisresults in the kfree() call in uvc_status_cleanup() trying todouble-free the memory. Fix it by resetting the dev->status pointer toNULL after freeing it.Reviewed by: Ricardo Ribalda

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57981 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix NULL pointer dereference on certain command abortsIf a command is queued to the final usable TRB of a ring segment, theenqueue pointer is advanced to the subsequent link TRB and no further.If the command is later aborted, when the abort completion is handledthe dequeue pointer is advanced to the first TRB of the next segment.If no further commands are queued, xhci_handle_stopped_cmd_ring() seesthe ring pointers unequal and assumes that there is a pending command,so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbellring likely is unnecessary too, but it's harmless. Leave it alone.This is probably Bug 219532, but no confirmation has been received.The issue has been independently reproduced and confirmed fixed usinga USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.Everything continued working normally after several prevented crashes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: fix out-of-bounds read during lookuplookup and resize can run in parallel.The xfrm_state_hash_generation seqlock ensures a retry, but the hashfunctions can observe a hmask value that is too large for the new hlistarray.rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {This is only safe in case the update to state_bydst is larger thannet->xfrm.xfrm_state_hmask (or if the lookup function getsserialized via state spinlock again).Fix this by prefetching state_hmask and the associated pointers.The xfrm_state_hash_generation seqlock retry will ensure that the pointerand the hmask will be consistent.The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,add lockdep assertions to document that they are only safe for insertside.xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.AFAICS this is an oversight from back when state lookup was converted toRCU, this lock should be replaced with RCU in a future patch.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Fix assumption that Resolution Multipliers must be in Logical CollectionsA report in 2019 by the syzbot fuzzer was found to be connected to twoerrors in the HID core associated with Resolution Multipliers. One ofthe errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloopin hid_apply_multiplier."), but the other has not been fixed.This error arises because hid_apply_multipler() assumes that everyResolution Multiplier control is contained in a Logical Collection,i.e., there's no way the routine can ever set multiplier_collection toNULL. This is in spite of the fact that the function starts with abig comment saying: * "The Resolution Multiplier control must be contained in the same * Logical Collection as the control(s) to which it is to be applied. ... * If no Logical Collection is * defined, the Resolution Multiplier is associated with all * controls in the report." * HID Usage Table, v1.12, Section 4.3.1, p30 * * Thus, search from the current collection upwards until we find a * logical collection...The comment and the code overlook the possibility that none of thecollections found may be a Logical Collection.The fix is to set the multiplier_collection pointer to NULL if thecollection found isn't a Logical Collection.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint checksyzbot has found a type mismatch between a USB pipe and the transferendpoint, which is triggered by the hid-thrustmaster driver[1].There is a number of similar, already fixed issues [2].In this case as in others, implementing check for endpoint type fixes the issue.[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Remove dangling pointersWhen an async control is written, we copy a pointer to the file handlethat started the operation. That pointer will be used when the device isdone. Which could be anytime in the future.If the user closes that file descriptor, its structure will be freed,and there will be one dangling pointer per pending async control, thatthe driver will try to use.Clean all the dangling pointers during release().To avoid adding a performance penalty in the most common case (no asyncoperation), a counter has been introduced with some logic to make surethat it is properly handled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: socinfo: Avoid out of bounds read of serial numberOn MSM8916 devices, the serial number exposed in sysfs is constant and doesnot change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does nothave support for the serial_num field in the socinfo struct. There is anexisting check to avoid exposing the serial number in that case, but it'snot correct: When checking the item_size returned by SMEM, we need to makesure the *end* of the serial_num is within bounds, instead of comparingwith the *start* offset. The serial_number currently exposed on MSM8916devices is just an out of bounds read of whatever comes after the socinfostruct in SMEM.Fix this by changing offsetof() to offsetofend(), so that the size of thefield is also taken into account.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: int3472: Check for adev == NULLNot all devices have an ACPI companion fwnode, so adev might be NULL. Thiscan e.g. (theoretically) happen when a user manually binds one ofthe int3472 drivers to another i2c/platform device through sysfs.Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58034 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()As of_find_node_by_name() release the reference of the argument devicenode, tegra_emc_find_node_by_ram_code() releases some device nodes whilestill in use, resulting in possible UAFs. According to the bindings andthe in-tree DTS files, the "emc-tables" node is always device's childnode with the property "nvidia,use-ram-code", and the "lpddr2" node is achild of the "emc-tables" node. Thus utilize thefor_each_child_of_node() macro and of_get_child_by_name() instead ofof_find_node_by_name() to simplify the code.This bug was found by an experimental verification tool that I amdeveloping.[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: ipmb: Add check devm_kasprintf() returned valuedevm_kasprintf() can return a NULL pointer on failure but thisreturned value is not checked.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix handling of received connection abortFix the handling of a connection abort that we've received. Though theabort is at the connection level, it needs propagating to the calls on thatconnection. Whilst the propagation bit is performed, the calls aren't thenwoken up to go and process their termination, and as no further input isforthcoming, they just hang.Also add some tracing for the logging of connection aborts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_tcm: Don't free command immediatelyDon't prematurely free the command. Wait for the status completion ofthe sense status. It can be freed then. Otherwise we will double-freethe command.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert workqueues to unboundWhen a workqueue is created with `WQ_UNBOUND`, its work items areserved by special worker-pools, whose host workers are not bound toany specific CPU. In the default configuration (i.e. when`queue_delayed_work` and friends do not specify which CPU to run thework item on), `WQ_UNBOUND` allows the work item to be executed on anyCPU in the same node of the CPU it was enqueued on. While thissolution potentially sacrifices locality, it avoids contention withother processes that might dominate the CPU time of the processor thework item was scheduled on.This is not just a theoretical problem: in a particular scenariomisconfigured process was hogging most of the time from CPU0, leavingless than 0.5% of its CPU time to the kworker. The IDPF workqueuesthat were using the kworker on CPU0 suffered large completion delaysas a result, causing performance degradation, timeouts and eventualsystem crash.* I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: skip dumping tnc tree when zroot is nullClearing slab cache will free all znode in memory and makec->zroot.znode = NULL, then dumping tnc tree will accessc->zroot.znode which cause null pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58063 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: fix memory leaks and invalid access at probe error pathDeinitialize at reverse order when probe fails.When init_sw_vars fails, rtl_deinit_core should not be called, speciallynow that it destroys the rtl_wq workqueue.And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will beleaked.Remove pci_set_drvdata call as it will already be cleaned up by the coredriver code and could lead to memory leaks too. cf. commit 8d450935ae7f("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") andcommit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM readThe nvmem interface supports variable buffer sizes, while the regmapinterface operates with fixed-size storage. If an nvmem client uses abuffer size less than 4 bytes, regmap_read will write out of boundsas it expects the buffer to point at an unsigned int.Fix this by using an intermediary unsigned int to hold the value.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:team: prevent adding a device which is already a team device lowerPrevent adding a device which is already a team device lower,e.g. adding veth0 if vlan1 was already added and veth0 is a lower ofvlan1.This is not useful in practice and can lead to recursive locking:$ ip link add veth0 type veth peer name veth1$ ip link set veth0 up$ ip link set veth1 up$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1$ ip link add team0 type team$ ip link set veth0.1 down$ ip link set veth0.1 master team0team0: Port device veth0.1 added$ ip link set veth0 down$ ip link set veth0 master team0============================================WARNING: possible recursive locking detected6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted--------------------------------------------ip/7684 is trying to acquire lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)but task is already holding lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)other info that might help us debug this:Possible unsafe locking scenario:CPU0----lock(team->team_lock_key);lock(team->team_lock_key);*** DEADLOCK ***May be due to missing lock nesting notation2 locks held by ip/7684:stack backtrace:CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:122)print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? lock_acquire (kernel/locking/lockdep.c:5822)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? fib_sync_up (net/ipv4/fib_semantics.c:2167)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)__dev_notify_flags (net/core/dev.c:8993)? __dev_change_flags (net/core/dev.c:8975)dev_change_flags (net/core/dev.c:9027)vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)? br_device_event (net/bridge/br.c:143)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)dev_open (net/core/dev.c:1519 net/core/dev.c:1505)team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)do_set_master (net/core/rtnetlink.c:2917)do_setlink.isra.0 (net/core/rtnetlink.c:3117)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: remove unused check_buddy_privCommit 2461c7d60f9f ("rtlwifi: Update header file") introduced a globallist of private data structures.Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to matchvendor version 2013.02.07") started adding the private data to that list atprobe time and added a hook, check_buddy_priv to find the private data froma similar device.However, that function was never used.Besides, though there is a lock for that list, it is never used. And whenthe probe fails, the private data is never removed from the list. Thiswould cause a second probe to access freed memory.Remove the unused hook, structures and members, which will prevent thepotential race condition on the list and its corruption during a secondprobe when probe fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix crash during unbind if gpio unit is in useWe used the wrong device for the device managed functions. We used theusb device, when we should be using the interface device.If we unbind the driver from the usb interface, the cleanup functionsare never called. In our case, the IRQ is never disabled.If an IRQ is triggered, it will try to access memory sections that arealready free, causing an OOPS.We cannot use the function devm_request_threaded_irq here. The devm_*clean functions may be called after the main structure is released byuvc_delete.Luckily this bug has small impact, as it is only affected by deviceswith gpio units and the user has to unbind the device, a disconnect willnot trigger this error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double accounting race when btrfs_run_delalloc_range() failed[BUG]When running btrfs with block size (4K) smaller than page size (64K,aarch64), there is a very high chance to crash the kernel atgeneric/750, with the following messages:(before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b[CAUSE]The above warning is triggered immediately after the delalloc rangefailure, this happens in the following sequence:- Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size)- Enter extent_writepage() for page 1536K- Enter run_delalloc_nocow() with locke---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free"), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free'd memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix RCU stall while reaping monitor destination ringWhile processing the monitor destination ring, MSDUs are reaped from thelink descriptor based on the corresponding buf_id.However, sometimes the driver cannot obtain a valid buffer correspondingto the buf_id received from the hardware. This causes an infinite loopin the destination processing, resulting in a kernel crash.kernel log:ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedFix this by skipping the problematic buf_id and reaping the next entry,replacing the break with the next MSDU processing.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: track changes_pkt_data property for global functionsWhen processing calls to certain helpers, verifier invalidates allpacket pointers in a current state. For example, consider thefollowing program: __attribute__((__noinline__)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP; skb_pull_data(sk, 0); *p = 42; return TCX_PASS; }After a call to bpf_skb_pull_data() the pointer 'p' can't be usedsafely. See function filter.c:bpf_helper_changes_pkt_data() for a listof such helpers.At the moment verifier invalidates packet pointers when processinghelper function calls, and does not traverse global sub-programs whenprocessing calls to global sub-programs. This means that calls tohelpers done from global sub-programs do not invalidate pointers inthe caller state. E.g. the program above is unsafe, but is notrejected by verifier.This commit fixes the omission by computing fieldbpf_subprog_info->changes_pkt_data for each sub-program before mainverification pass.changes_pkt_data should be set if:- subprogram calls helper for which bpf_helper_changes_pkt_data returns true;- subprogram calls a global function, for which bpf_subprog_info->changes_pkt_data should be set.The verifier.c:check_cfg() pass is modified to compute thisinformation. The commit relies on depth first instruction traversaldone by check_cfg() and absence of recursive function calls:- check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored;- when S is fully explored: - every direct helper call within S is explored (and thus changes_pkt_data is set if needed); - every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1).The downside of such approach is that dead code elimination is nottaken into account: if a helper call inside global function is deadbecause of current configuration, verifier would conservatively assumethat the call occurs for the purpose of the changes_pkt_datacomputation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58100 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: check changes_pkt_data property for extension programsWhen processing calls to global sub-programs, verifier decides whetherto invalidate all packet pointers in current state depending on thechanges_pkt_data property of the global sub-program.Because of this, an extension program replacing a global sub-programmust be compatible with changes_pkt_data property of the sub-programbeing replaced.This commit:- adds changes_pkt_data flag to struct bpf_prog_aux: - this flag is set in check_cfg() for main sub-program; - in jit_subprogs() for other sub-programs;- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;- moves call to check_attach_btf_id() after the call to check_cfg(), because it needs changes_pkt_data flag to be set: bpf_check: ... ... - check_attach_btf_id resolve_pseudo_ldimm64 resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded bpf_prog_is_offloaded check_cfg check_cfg + check_attach_btf_id ... ...The following fields are set by check_attach_btf_id():- env->ops- prog->aux->attach_btf_trace- prog->aux->attach_func_name- prog->aux->attach_func_proto- prog->aux->dst_trampoline- prog->aux->mod- prog->aux->saved_dst_attach_type- prog->aux->saved_dst_prog_type- prog->expected_attach_typeNeither of these fields are used by resolve_pseudo_ldimm64() orbpf_prog_offload_verifier_prep() (for netronome and netdevsimdrivers), so the reordering is safe.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: consider that tail calls invalidate packet pointersTail-called programs could execute any of the helpers that invalidatepacket pointers. Hence, conservatively assume that each tail callinvalidates packet pointers.Making the change in bpf_helper_changes_pkt_data() automatically makesuse of check_cfg() logic that computes 'changes_pkt_data' effect forglobal sub-programs, such that the following program could berejected: int tail_call(struct __sk_buff *sk) { bpf_tail_call_static(sk, &jmp_table, 0); return 0; } SEC("tc") int not_safe(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; ... make p valid ... tail_call(sk); *p = 42; /* this is unsafe */ ... }The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function thatcan invalidate packet pointers. Otherwise, it can't be freplaced withtailcall_freplace.c:entry_freplace() that does a tail call.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.probe_interval' isused.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: udp_port: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix the maximum cell name lengthThe kafs filesystem limits the maximum length of a cell to 256 bytes, but aproblem occurs if someone actually does that: kafs tries to create adirectory under /proc/net/afs/ with the name of the cell, but that failswith a warning: WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405because procfs limits the maximum filename length to 255.However, the DNS limits the maximum lookup length and, by extension, themaximum cell name, to 255 less two (length count and trailing NUL).Fix this by limiting the maximum acceptable cellname length to 253. Thisalso allows us to be sure we can create the "/afs/./" mountpoint too.Further, split the YFS VL record cell name maximum to be the 256 allowed bythe protocol and ignore the record retrieved by YFSVL.GetCellName if itexceeds 253.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is sent on HIP08 devicesCurrently, HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL. But the tx process would still try to set hardware timestamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge][ 128.292938] sp : ffff800059b93140[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001[ 128.315969] x23: 0000000000000000 x22: 0000000000000194[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080[ 128.390626] Call trace:[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3][ 128.405468] xmit_one.constprop.0+0xc4/0x200[ 128.410600] dev_hard_start_xmit+0x54/0xf0[ 128.415556] sch_direct_xmit+0xe8/0x634[ 128.420246] __dev_queue_xmit+0x224/0xc70[ 128.425101] dev_queue_xmit+0x1c/0x40[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch][ 128.435409] do_output+0x60/0x17c [openvswitch][ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch][ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch][ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch][ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch][ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch][ 128.471460] xmit_one.constprop.0+0xc4/0x200[ 128.476561] dev_hard_start_xmit+0x54/0xf0[ 128.481489] __dev_queue_xmit+0x968/0xc70[ 128.486330] dev_queue_xmit+0x1c/0x40[ 128.490856] ip_finish_output2+0x250/0x570[ 128.495810] __ip_finish_output+0x170/0x1e0[ 128.500832] ip_finish_output+0x3c/0xf0[ 128.505504] ip_output+0xbc/0x160[ 128.509654] ip_send_skb+0x58/0xd4[ 128.513892] udp_send_skb+0x12c/0x354[ 128.518387] udp_sendmsg+0x7a8/0x9c0[ 128.522793] inet_sendmsg+0x4c/0x8c[ 128.527116] __sock_sendmsg+0x48/0x80[ 128.531609] __sys_sendto+0x124/0x164[ 128.536099] __arm64_sys_sendto+0x30/0x5c[ 128.540935] invoke_syscall+0x50/0x130[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124[ 128.551205] do_el0_svc+0x34/0xdc[ 128.555347] el0_svc+0x20/0x30[ 128.559227] el0_sync_handler+0xb8/0xc0[ 128.563883] el0_sync+0x160/0x180

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid NULL pointer dereference if no valid extent tree[BUG]Syzbot reported a crash with the following call trace: BTRFS info (device loop0): scrub: started on devid 1 BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs] scrub_simple_mirror+0x175/0x260 [btrfs] scrub_stripe+0x5d4/0x6c0 [btrfs] scrub_chunk+0xbb/0x170 [btrfs] scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs] btrfs_scrub_dev+0x240/0x600 [btrfs] btrfs_ioctl+0x1dc8/0x2fa0 [btrfs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE]The reproducer is using a corrupted image where extent tree root iscorrupted, thus forcing to use "rescue=all,ro" mount option to mount theimage.Then it triggered a scrub, but since scrub relies on extent tree to findwhere the data/metadata extents are, scrub_find_fill_first_stripe()relies on an non-empty extent root.But unfortunately scrub_find_fill_first_stripe() doesn't really expectan NULL pointer for extent root, it use extent_root to grab fs_info andtriggered a NULL pointer dereference.[FIX]Add an extra check for a valid extent root at the beginning ofscrub_find_fill_first_stripe().The new error path is introduced by 42437a6386ff ("btrfs: introducemount option rescue=ignorebadroots"), but that's pretty old, and latercommit b979547513ff ("btrfs: scrub: introduce helper to find and fillsector info for a scrub_stripe") changed how we do scrub.So for kernels older than 6.6, the fix will need manual backport.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]Recent reports have shown how we sometimes call vsock_*_has_data()when a vsock socket has been de-assigned from a transport (see attachedlinks), but we shouldn't.Previous commits should have solved the real problems, but we may havemore in the future, so to avoid null-ptr-deref, we can return 0(no space, no data available) but with a warning.This way the code should continue to run in a nearly consistent stateand have a warning that allows us to debug future problems.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clear port select structure when fail to createClear the port select structure on error so no stale values left afterdefiners are destroyed. That's because the mlx5_lag_destroy_definers()always try to destroy all lag definers in the tt_map, so in the flowbelow lag definers get double-destroyed and cause kernel crash: mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 1 mlx5_lag_destroy_definers() <- definers[tt=0] gets destroyed mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 0 mlx5_lag_destroy_definers() <- definers[tt=0] gets double-destroyed Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core] mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core] mlx5_activate_lag+0x60c/0x6f8 [mlx5_core] mlx5_do_bond_work+0x284/0x5c8 [mlx5_core] process_one_work+0x170/0x3e0 worker_thread+0x2d8/0x3e0 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mm: clear uffd-wp PTE/PMD state on mremap()When mremap()ing a memory region previously registered with userfaultfd aswrite-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency inflag clearing leads to a mismatch between the vma flags (which haveuffd-wp cleared) and the pte/pmd flags (which do not have uffd-wpcleared). This mismatch causes a subsequent mprotect(PROT_WRITE) totrigger a warning in page_table_check_pte_flags() due to setting the pteto writable while uffd-wp is still set.Fix this by always explicitly clearing the uffd-wp pte/pmd flags on anysuch mremap() so that the values are consistent with the existing clearingof VM_UFFD_WP. Be careful to clear the logical flag regardless of itsphysical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE,huge PMD and hugetlb paths.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: consolidate suboption statusMPTCP maintains the received sub-options status is the bitmask carryingthe received suboptions and in several bitfields carrying per suboptionadditional info.Zeroing the bitmask before parsing is not enough to ensure a consistentstatus, and the MPTCP code has to additionally clear some bitfileddepending on the actually parsed suboption.The above schema is fragile, and syzbot managed to trigger a path wherea relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: davicom: fix UAF in dm9000_drv_removedm is netdev private data and it cannot beused after free_netdev() call. Using dm after free_netdev()can cause UAF bug. Fix it by moving free_netdev() at the end of thefunction.This is similar to the issue fixed in commitad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").This bug is detected by our static analysis tool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipmr: do not call mr_mfc_uses_dev() for unres entriessyzbot found that calling mr_mfc_uses_dev() for unres entrieswould crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvifalias to "struct sk_buff_head unresolved", which contain two pointers.This code never worked, lets remove it.[1]Unable to handle kernel paging request at virtual address ffff5fff2d536613KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]Modules linked in:CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:padata: fix UAF in padata_reorderA bug was found when run ltp test:BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+Workqueue: pdecrypt_parallel padata_parallel_workerCall Trace:dump_stack_lvl+0x32/0x50print_address_description.constprop.0+0x6b/0x3d0print_report+0xdd/0x2c0kasan_report+0xa5/0xd0padata_find_next+0x29/0x1a0padata_reorder+0x131/0x220padata_parallel_worker+0x3d/0xc0process_one_work+0x2ec/0x5a0If 'mdelay(10)' is added before calling 'padata_find_next' in the'padata_reorder' function, this issue could be reproduced easily withltp test (pcrypt_aead01).This can be explained as bellow:pcrypt_aead_encrypt...padata_do_parallelrefcount_inc(&pd->refcnt); // add refcnt...padata_do_serialpadata_reorder // pdwhile (1) {padata_find_next(pd, true); // using pdqueue_work_on...padata_serial_worker crypto_del_algpadata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed// loop again, but pd is freed// call padata_find_next, UAF}In the padata_reorder function, when it loops in 'while', if the alg isdeleted, the refcnt may be decreased to 0 before entering'padata_find_next', which leads to UAF.As mentioned in [1], do_serial is supposed to be called with BHs disabledand always happen under RCU protection, to address this issue, addsynchronize_rcu() in 'padata_free_shell' wait for all _do_serial callsto finish.[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Send signals asynchronously if !preemptibleBPF programs can execute in all kinds of contexts and when a programrunning in a non-preemptible context uses the bpf_send_signal() kfunc,it will cause issues because this kfunc can sleep.Change `irqs_disabled()` to `!preemptible()`.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: don't allow reconnect after disconnectFollowing process can cause nbd_config UAF:1) grab nbd_config temporarily;2) nbd_genl_disconnect() flush all recv_work() and release theinitial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work)4) step 1) release the reference;5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAFFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), sothat nbd_genl_reconfigure() will fail.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix copy buffer page sizeFor non-registered buffer, fastrpc driver copies the buffer andpass it to the remote subsystem. There is a problem with currentimplementation of page size calculation which is not consideringthe offset in the calculation. This might lead to passing ofimproper and out-of-bounds page size which could result inmemory issue. Calculate page start and page end using the offsetadjusted address instead of absolute address.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix possible int overflows in nilfs_fiemap()Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its resultby being prepared to go through potentially maxblocks == INT_MAX blocks,the value in n may experience an overflow caused by left shift of blkbits.While it is extremely unlikely to occur, play it safe and cast right handexpression to wider type to mitigate the issue.Found by Linux Verification Center (linuxtesting.org) with static analysistool SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix class @block_class's subsystem refcount leakageblkcg_fill_root_iostats() iterates over @block_class's devices byclass_dev_iter_(init|next)(), but does not end iterating withclass_dev_iter_exit(), so causes the class's subsystem refcount leakage.Fix by ending the iterating with class_dev_iter_exit().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the return value of of_property_read_string_index()Somewhen between 6.10 and 6.11 the driver started to crash on myMacBookPro14,3. The property doesn't exist and 'tmp' remainsuninitialized, so we pass a random pointer to devm_kstrdup().The crash I am getting looks like this:BUG: unable to handle page fault for address: 00007f033c669379PF: supervisor read access in kernel modePF: error_code(0x0001) - permissions violationPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025Oops: Oops: 0001 [#1] SMP PTICPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024RIP: 0010:strlen+0x4/0x30Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 ccRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916aR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: extend RCU protection in ndisc_send_skb()ndisc_send_skb() can be called without RTNL or RCU held.Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()and avoid a potential UAF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: use RCU protection in ovs_vport_cmd_fill_info()ovs_vport_cmd_fill_info() can be called without RTNL or RCU.Use RCU protection and dev_net_rcu() to avoid potential UAF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: use RCU protection in ndisc_alloc_skb()ndisc_alloc_skb() can be called without RTNL or RCU being held.Add RCU protection to avoid possible UAF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU protection in ip6_default_advmss()ip6_default_advmss() needs rcu protection to makesure the net structure it reads does not disappear.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: use RCU protection in __ip_rt_update_pmtu()__ip_rt_update_pmtu() must use RCU protection to makesure the net structure it reads does not disappear.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic contextThe following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0It is due to the fact that clocksource_verify_choose_cpus() is invoked withpreemption disabled. This function invokes get_random_u32() to obtainrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/orthe base_crng.lock spinlock in driver/char/random.c will be acquired duringthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannotbe acquired in atomic context.Fix this problem by using migrate_disable() to allow smp_processor_id() tobe reliably used without introducing atomic context. preempt_disable() isthen called after clocksource_verify_choose_cpus() but before theclocksource measurement is being run to avoid introducing unexpectedlatency.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix panic during interface removalReference counting is used to ensure thatbatadv_hardif_neigh_node and batadv_hard_ifaceare not freed before/duringbatadv_v_elp_throughput_metric_update work isfinished.But there isn't a guarantee that the hard if willremain associated with a soft interface up untilthe work is finished.This fixes a crash triggered by reboot that lookslike this:Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20(the batadv_v_mesh_free call is misleading,and does not actually happen)I was able to make the issue happen more reliablyby changing hardif_neigh->bat_v.metric_work workto be delayed work. This allowed me to track downand confirm the fix.[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockoptIf an AX25 device is bound to a socket by setting the SO_BINDTODEVICEsocket option, a refcount leak will occur in ax25_release().Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")added decrement of device refcounts in ax25_release(). In order for thatto work correctly the refcounts must already be incremented when thedevice is bound to the socket. An AX25 device can be bound to a socketby either calling ax25_bind() or setting SO_BINDTODEVICE socket option.In both cases the refcounts should be incremented, but in fact it is doneonly in ax25_bind().This bug leads to the following issue reported by Syzkaller:================================================================refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Modules linked in:CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ... do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Fix the implementation of ax25_setsockopt() by adding increment ofrefcounts for the new device bound, and decrement of refcounts forthe old unbound device.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()When getting the IRQ we use k3_udma_glue_tx_get_irq() which returnsnegative error value on error. So not NULL check is not sufficientto deteremine if IRQ is valid. Check that IRQ is greater then zeroto ensure it is valid.There is no issue at probe time but at runtime user can invoke.set_channels which results in the following call chain.am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns()At this point if am65_cpsw_nuss_init_tx_chns() fails due tok3_udma_glue_tx_get_irq() then tx_chn->irq will be set to anegative value.Then, at subsequent .set_channels with higher channel count wewill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()leading to a kernel warning.The issue is present in the original commit that introduced this driver,although there, am65_cpsw_nuss_update_tx_rx_chns() existed asam65_cpsw_nuss_update_tx_chns().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: ravb: Fix missing rtnl lock in suspend/resume pathFix the suspend/resume path by ensuring the rtnl lock is held whererequired. Calls to ravb_open, ravb_close and wol operations must beperformed under the rtnl lock to prevent conflicts with ongoing ndooperations.Without this fix, the following warning is triggered:[ 39.032969] =============================[ 39.032983] WARNING: suspicious RCU usage[ 39.033019] -----------------------------[ 39.033033] drivers/net/phy/phy_device.c:2004 suspiciousrcu_dereference_protected() usage!...[ 39.033597] stack backtrace:[ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7[ 39.033623] Hardware name: Renesas SMARC EVK version 2 based onr9a08g045s33 (DT)[ 39.033628] Call trace:[ 39.033633] show_stack+0x14/0x1c (C)[ 39.033652] dump_stack_lvl+0xb4/0xc4[ 39.033664] dump_stack+0x14/0x1c[ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c[ 39.033682] phy_detach+0x160/0x190[ 39.033694] phy_disconnect+0x40/0x54[ 39.033703] ravb_close+0x6c/0x1cc[ 39.033714] ravb_suspend+0x48/0x120[ 39.033721] dpm_run_callback+0x4c/0x14c[ 39.033731] device_suspend+0x11c/0x4dc[ 39.033740] dpm_suspend+0xdc/0x214[ 39.033748] dpm_suspend_start+0x48/0x60[ 39.033758] suspend_devices_and_enter+0x124/0x574[ 39.033769] pm_suspend+0x1ac/0x274[ 39.033778] state_store+0x88/0x124[ 39.033788] kobj_attr_store+0x14/0x24[ 39.033798] sysfs_kf_write+0x48/0x6c[ 39.033808] kernfs_fop_write_iter+0x118/0x1a8[ 39.033817] vfs_write+0x27c/0x378[ 39.033825] ksys_write+0x64/0xf4[ 39.033833] __arm64_sys_write+0x18/0x20[ 39.033841] invoke_syscall+0x44/0x104[ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4[ 39.033862] do_el0_svc+0x18/0x20[ 39.033870] el0_svc+0x3c/0xf0[ 39.033880] el0t_64_sync_handler+0xc0/0xc4[ 39.033888] el0t_64_sync+0x154/0x158[ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix oops when unload drivers parallelingWhen unload hclge driver, it tries to disable sriov first for eachae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver atthe time, because it removes all the ae_dev nodes, and it may causeoops.But we can't simply use hnae3_common_lock for this. Because in theprocess flow of pci_disable_sriov(), it will trigger the remove flowof VF, which will also take hnae3_common_lock.To fixes it, introduce a new mutex to protect the unload process.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()macro to request a needed resource. A string variable that lives on thestack is then used to store a dynamically computed resource name, whichis then passed on as one of the macro arguments. This can lead toundefined behavior.Depending on the current contents of the memory, the manifestations oferrors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :Sometimes, garbage may appear after the colon.In very rare cases, if no NULL-terminator is found in memory, the systemmight crash because the string iterator will overrun which can lead toaccess of unmapped memory above the stack.Thus, fix this by replacing outbound_name with the name of the previouslyrequested resource. With the changes applied, the output will be asfollows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3[kwilczynski: commit log]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi's weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi's weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Drop unmanaged ELP metric workerThe ELP worker needs to calculate new metric values for all neighbors"reachable" over an interface. Some of the used metric sources requirelocks which might need to sleep. This sleep is incompatible with the RCUlist iterator used for the recorded neighbors. The initial approach to workaround of this problem was to queue another work item per neighbor and thenrun this in a new context.Even when this solved the RCU vs might_sleep() conflict, it has a majorproblems: Nothing was stopping the work item in case it is not neededanymore - for example because one of the related interfaces was removed orthe batman-adv module was unloaded - resulting in potential invalid memoryaccesses.Directly canceling the metric worker also has various problems:* cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.* iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)The better approch is to get rid of the per interface neighbor metricworker and handle everything in the interface worker. The original problemsare solved by:* creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context* only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Handle weird filesA corrupted filesystem (e.g. bcachefs) might return weird files.Instead of throwing a warning and allowing access to such file, treatthem as regular files.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_midi: fix MIDI Streaming descriptor lengthsWhile the MIDI jacks are configured correctly, and the MIDIStreamingendpoint descriptors are filled with the correct information,bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.This does not matter when the numbers of in and out ports are equal, butwhen they differ the host will receive broken descriptors withuninitialized stack memory leaking into the descriptor for whichevervalue is smaller.The precise meaning of "in" and "out" in the port counts is not clearlydefined and can be confusing. But elsewhere the driver consistentlyuses this to match the USB meaning of IN and OUT viewed from the host,so that "in" ports send data to the host and "out" ports receive datafrom it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Add check for next_buffer in receive_encrypted_standard()Add check for the return value of cifs_buf_get() and cifs_small_buf_get()in receive_encrypted_standard() to prevent null pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:acct: perform last write from workqueueIn [1] it was reported that the acct(2) system call can be used totrigger NULL deref in cases where it is set to write to a file thattriggers an internal lookup. This can e.g., happen when pointing acc(2)to /sys/power/resume. At the point the where the write to this filehappens the calling task has already exited and called exit_fs(). Alookup will thus trigger a NULL-deref when accessing current->fs.Reorganize the code so that the the final write happens from theworkqueue but with the caller's credentials. This preserves the(strange) permission model and has almost no regression risk.This api should stop to exist though.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()Add check for the return value of nfp_app_ctrl_msg_alloc() innfp_bpf_cmsg_alloc() to prevent null pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: avoid holding freeze_mutex during mmap operationWe use map->freeze_mutex to prevent races between map_freeze() andmemory mapping BPF map contents with writable permissions. The way wenaively do this means we'll hold freeze_mutex for entire duration of allthe mm and VMA manipulations, which is completely unnecessary. This canpotentially also lead to deadlocks, as reported by syzbot in [0].So, instead, hold freeze_mutex only during writeability checks, bump(proactively) "write active" count for the map, unlock the mutex andproceed with mmap logic. And only if something went wrong during mmaplogic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)->geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let's call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: f_midi: f_midi_complete to call queue_workWhen using USB MIDI, a lock is attempted to be acquired twice through are-entrant call to f_midi_transmit, causing a deadlock.Fix it by using queue_work() to schedule the inner f_midi_transmit() viaa high priority work queue from the completion handler.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()If migration succeeded, we calledfolio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from theold to the new folio. This will set memcg_data of the old folio to 0.Similarly, if migration failed, memcg_data of the dst folio is left unset.If we call folio_putback_lru() on such folios (memcg_data == 0), we willadd the folio to be freed to the LRU, making memcg code unhappy. Runningthe hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80Likely, nothing else goes wrong: putting the last folio reference willremove the folio from the LRU again. So besides memcg complaining, addingthe folio to be freed to the LRU is just an unnecessary step.The new flow resembles what we have in migrate_folio_move(): add the dstto the lru, rem---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: fix incorrect initialization orderSyzkaller reports the following bug:BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7RIP: 0033:0x7f3f9815aee9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768If drop_monitor is built as a kernel module, syzkaller may have timeto send a netlink NET_DM_CMD_START message during the module loading.This will call the net_dm_monitor_start() function that usesa spinlock that has not yet been initialized.To fix this, let's place resource initialization above the registrationof a generic netlink family.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: prevent opcode speculationsqe->opcode is used for different tables, make sure we santitise itagainst speculations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOCErhard reported the following KASAN hit while booting his PowerMac G4with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================f8 corresponds to KASAN_VMALLOC_INVALID which means the area is notinitialised hence not supposed to be used yet.Powerpc text patching infrastructure allocates a virtual memory areausing get_vm_area() and flags it as VM_ALLOC. But that flag is meantto be used for vmalloc() and vmalloc() allocated memory is notsupposed to be used before a call to __vmalloc_node_range() which isnever called for that area.That went undetected until commit e4137f08816b ("mm, kasan, kmsan:instrument copy_from/to_kernel_nofault")The area allocated by text_area_cpu_up() is not vmalloc memory, it ismapped directly on demand when needed by map_kernel_page(). There isno VM flag corresponding to such usage, so just pass no flag. That waythe area will be unpoisonned and usable immediately.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix supplicant wait loopOP-TEE supplicant is a user-space daemon and it's possible for itbe hung or crashed or killed in the middle of processing an OP-TEERPC call. It becomes more complicated when there is incorrect shutdownordering of the supplicant process vs the OP-TEE client application whichcan eventually lead to system hang-up waiting for the closure of theclient application.Allow the client process waiting in kernel for supplicant response tobe killed rather than indefinitely waiting in an unkillable state. Also,a normal uninterruptible wait should not have resulted in the hung-taskwatchdog getting triggered, but the endless loop would.This fixes issues observed during system reboot/shutdown when supplicantgot hung for some reason or gets crashed/killed which lead to clientgetting hung in an unkillable state. It in turn lead to system being inhung up state requiring hard power off/on to recover.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:efi: Don't map the entire mokvar table to determine its sizeCurrently, when validating the mokvar table, we (re)map the entire tableon each iteration of the loop, adding space as we discover new entries.If the table grows over a certain size, this fails due to limitations ofearly_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.Mapping the entire structure isn't actually necessary, as we don't everneed more than one entry header mapped at once.Changes efi_mokvar_table_init() to only map each entry header, not theentire table, when determining the table size. Since we're not mappingany data past the variable name, it also changes the code to enforcethat each variable name is NUL terminated, rather than attempting toverify it in place.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: always handle address removal under msk socket lockSyzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088Indeed the PM can try to send a RM_ADDR over a msk without acquiringfirst the msk socket lock.The bugged code-path comes from an early optimization: when thereare no subflows, the PM should (usually) not send RM_ADDRnotifications.The above statement is incorrect, as without locks another processcould concur---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: npcm: disable interrupt enable bit before devm_request_irqThe customer reports that there is a soft lockup issue related tothe i2c driver. After checking, the i2c module was doing a tx transferand the bmc machine reboots in the middle of the i2c transaction, the i2cmodule keeps the status without being reset.Due to such an i2c module status, the i2c irq handler keeps gettingtriggered since the i2c irq handler is registered in the kernel bootingprocess after the bmc machine is doing a warm rebooting.The continuous triggering is stopped by the soft lockup watchdog timer.Disable the interrupt enable bit in the i2c module before callingdevm_request_irq to fix this issue since the i2c relative status bitis read-only.Here is the soft lockup log.[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1][ 28.183351] Modules linked in:[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 28.208128] pc : __do_softirq+0xb0/0x368[ 28.212055] lr : __do_softirq+0x70/0x368[ 28.215972] sp : ffffff8035ebca00[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40[ 28.290611] Call trace:[ 28.293052] __do_softirq+0xb0/0x368[ 28.296625] __irq_exit_rcu+0xe0/0x100[ 28.300374] irq_exit+0x14/0x20[ 28.303513] handle_domain_irq+0x68/0x90[ 28.307440] gic_handle_irq+0x78/0xb0[ 28.311098] call_on_irq_stack+0x20/0x38[ 28.315019] do_interrupt_handler+0x54/0x5c[ 28.319199] el1_interrupt+0x2c/0x4c[ 28.322777] el1h_64_irq_handler+0x14/0x20[ 28.326872] el1h_64_irq+0x74/0x78[ 28.330269] __setup_irq+0x454/0x780[ 28.333841] request_threaded_irq+0xd0/0x1b4[ 28.338107] devm_request_threaded_irq+0x84/0x100[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0[ 28.346990] platform_probe+0x6c/0xc4[ 28.350653] really_probe+0xcc/0x45c[ 28.354227] __driver_probe_device+0x8c/0x160[ 28.358578] driver_probe_device+0x44/0xe0[ 28.362670] __driver_attach+0x124/0x1d0[ 28.366589] bus_for_each_dev+0x7c/0xe0[ 28.370426] driver_attach+0x28/0x30[ 28.373997] bus_add_driver+0x124/0x240[ 28.377830] driver_register+0x7c/0x124[ 28.381662] __platform_driver_register+0x2c/0x34[ 28.386362] npcm_i2c_init+0x3c/0x5c[ 28.389937] do_one_initcall+0x74/0x230[ 28.393768] kernel_init_freeable+0x24c/0x2b4[ 28.398126] kernel_init+0x28/0x130[ 28.401614] ret_from_fork+0x10/0x20[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks[ 28.411011] SMP: stopping secondary CPUs[ 28.414933] Kernel Offset: disabled[ 28.418412] CPU features: 0x00000000,00000802[ 28.427644] Rebooting in 20 seconds..

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Fix the page details for the srq created by kernel consumersWhile using nvme target with use_srq on, below kernel panic is noticed.[ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)[ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI..[ 566.393799] [ 566.393807] ? __die_body+0x1a/0x60[ 566.393823] ? die+0x38/0x60[ 566.393835] ? do_trap+0xe4/0x110[ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393881] ? do_error_trap+0x7c/0x120[ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393911] ? exc_divide_error+0x34/0x50[ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393939] ? asm_exc_divide_error+0x16/0x20[ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re][ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re][ 566.394057] ? srso_return_thunk+0x5/0x5f[ 566.394068] ? __init_swait_queue_head+0x4a/0x60[ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core][ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma][ 566.394174] ? lock_release+0x22c/0x3f0[ 566.394187] ? srso_return_thunk+0x5/0x5fPage size and shift info is set only for the user space SRQs.Set page size and page shift for kernel space SRQs also.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix checksums set in idpf_rx_rsc()idpf_rx_rsc() uses skb_transport_offset(skb) while the transport headeris not set yet.This triggers the following warning for CONFIG_DEBUG_NET=y builds.DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))[ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth[ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697[ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)[ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261687] ? report_bug (lib/bug.c:?)[ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)[ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)[ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf[ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf[ 69.261712] __napi_poll (net/core/dev.c:7194)[ 69.261716] net_rx_action (net/core/dev.c:7265)[ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)[ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)[ 69.261726] handle_softirqs (kernel/softirq.c:561)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: ensure network headers are in skb linear partsyzbot found that ipvlan_process_v6_outbound() was assumingthe IPv6 network header isis present in skb->head [1]Add the needed pskb_network_may_pull() calls for bothIPv4 and IPv6 handlers.[1]BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNCActually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because onlyENETC PF can access PMa_SINGLE_STEP registers. And there will be a crashif VFs are used to test one-step timestamp, the crash log as follows.[ 129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0[ 129.287769] Call trace:[ 129.290219] enetc_port_mac_wr+0x30/0xec (P)[ 129.294504] enetc_start_xmit+0xda4/0xe74[ 129.298525] enetc_xmit+0x70/0xec[ 129.301848] dev_hard_start_xmit+0x98/0x118

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don't care about rec->counter * rec->counter overflow becauserec->time * rec->time overflow will likely happen earlier.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix bad hist from corrupting named_triggers listThe following commands causes a crash: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=common_pid' > triggerBecause the following occurs:event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg;[..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)[..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- NEVER gets removed! } } } } [..] kfree(data); <<<-- frees item but it is still on listThe next time a hist with name is registered, it causes an u-a-f bug andthe kernel can crash.Move the code around such that if event_trigger_register() succeeds, thenext thing called is hist_trigger_enable() which adds it to the list.A bunch of actions is called if get_named_trigger_data() returns false.But that doesn't need to be called after event_trigger_register(), so itcan be moved up, allowing event_trigger_register() to be called justbefore hist_trigger_enable() keeping them together and allowing thefile->triggers to be properly populated.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:caif_virtio: fix wrong pointer check in cfv_probe()del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checkedfor NULL before calling it, not cfv->vdev. Also the current implementationis redundant because the pointer cfv->vdev is dereferenced before it ischecked for NULL.Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev beforecalling del_vqs().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: limit printed string from FW fileThere's no guarantee here that the file is always with aNUL-termination, so reading the string may read beyond theend of the TLV. If that's the last TLV in the file, it canperhaps even read beyond the end of the file buffer.Fix that by limiting the print format to the size of thebuffer we have.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject cooked mode if it is set along with other flagsIt is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVEflags simultaneously on the same monitor interface from the userspace. Thiscauses a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bitset because the monitor interface is in the cooked state and it takesprecedence over all other states. When the interface is then being deletedthe kernel calls WARN_ONCE() from check_sdata_in_driver() because of missingthat bit.Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along withother flags.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: regulatory: improve invalid hints checkingSyzbot keeps reporting an issue [1] that occurs when erroneous symbolssent from userspace get through into user_alpha2[] viaregulatory_hint_user() call. Such invalid regulatory hints should berejected.While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:reject invalid hints") looks to be enough to deter these very cases,there is a way to get around it due to 2 reasons.1) The way isalpha() works, symbols other than latin lower andupper letters may be used to determine a country/domain.For instance, greek letters will also be considered upper/lowerletters and for such characters isalpha() will return true as well.However, ISO-3166-1 alpha2 codes should only hold latincharacters.2) While processing a user regulatory request, betweenreg_process_hint_user() and regulatory_hint_user() there happens tobe a call to queue_regulatory_request() which modifies letters inrequest->alpha2[] with toupper(). This works fine for latin symbols,less so for weird letter characters from the second part of _ctype[].Syzbot triggers a warning in is_user_regdom_saved() by first sendingover an unexpected non-latin letter that gets malformed by toupper()into a character that ends up failing isalpha() check.Prevent this by enhancing is_an_alpha2() to ensure that incomingsymbols are latin letters and nothing else.[1] Syzbot report:------------[ cut here ]------------Unexpected user alpha2: A�WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516Modules linked in:CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events_power_efficient crda_timeout_workRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516...Call Trace: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Flush the notify_hotplug_workWhen performing continuous unbind/bind operations on the USB driversavailable on the Renesas RZ/G2L SoC, a kernel crash with the message"Unable to handle kernel NULL pointer dereference at virtual address"may occur. This issue points to the usbhsc_notify_hotplug() function.Flush the delayed work to avoid its execution when driver resources areunavailable.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Fix potential memory corruption in child_cfs_rq_on_listchild_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,making the conversion invalid and potentially leading to memorycorruption. Depending on the relative positions of leaf_cfs_rq_list andthe task group (tg) pointer within the struct, this can cause a memoryfault or access garbage data.The issue arises in list_add_leaf_cfs_rq, where bothcfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the sameleaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the mainconditional in child_cfs_rq_on_list. This ensures that the container_ofoperation will convert a correct cfs_rq struct.This check is sufficient because only cfs_rqs on the same CPU are addedto the list, so verifying the 'prev' pointer against the current rq's listhead is enough.Fixes a potential memory corruption issue that due to current structlayout might not be manifesting as a crash but could lead to unpredictablebehavior when the layout changes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vlan: enforce underlying device typeCurrently, VLAN devices can be created on top of non-ethernet devices.Besides the fact that it doesn't make much sense, this also causes abug which leaks the address of a kernel function to usermode.When creating a VLAN device, we initialize GARP (garp_init_applicant)and MRP (mrp_init_applicant) for the underlying device.As part of the initialization process, we add the multicast address ofeach applicant to the underlying device, by calling dev_mc_add.__dev_mc_add uses dev->addr_len to determine the length of the newmulticast address.This causes an out-of-bounds read if dev->addr_len is greater than 6,since the multicast addresses provided by GARP and MRP are only 6bytes long.This behaviour can be reproduced using the following commands:ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev loip l set up dev gretestip link add link gretest name vlantest type vlan id 100Then, the following command will display the address of garp_pdu_rcv:ip maddr show | grep 01:80:c2:00:00:21Fix the bug by enforcing the type of the underlying device during VLANdevice initialization.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an errorDuring the initialization of ptp, hclge_ptp_get_cycle might return an errorand returned directly without unregister clock and free it. To avoid that,call hclge_ptp_destroy_clock to unregist and free clock ifhclge_ptp_get_cycle failed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:llc: do not use skb_get() before dev_queue_xmit()syzbot is able to crash hosts [1], using llc and devicesnot supporting IFF_TX_SKB_SHARING.In this case, e1000 driver calls eth_skb_pad(), whilethe skb is shared.Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.cNote that e1000 driver might have an issue with pktgen,because it does not clear IFF_TX_SKB_SHARING, this is anorthogonal change.We need to audit other skb_get() uses in net/llc.[1]kernel BUG at net/core/skbuff.c:2178 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178Call Trace: __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [inline]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix ownership in __udp_gso_segmentIn __udp_gso_segment the skb destructor is removed before segmenting theskb but the socket reference is kept as-is. This is an issue if theoriginal skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50The above can happen following a sequence of events when usingOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes anOVS_ACTION_ATTR_OUTPUT action:1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed.2. The segments' data are copied and sent to userspace.3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path.4. If it later hits skb_orphan, we hit the bug.Fix this by also removing the reference to the socket in__udp_gso_segment.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()nvme_tcp_recv_pdu() doesn't check the validity of the header length.When header digests are enabled, a target might send a packet with aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folioCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages tobe offlined) add page poison checks in do_migrate_range in order to makeoffline hwpoisoned page possible by introducing isolate_lru_page andtry_to_unmap for hwpoisoned page. However folio lock must be held beforecalling try_to_unmap. Add it to fix this problem.Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: fix an API misues when rio_add_net() failsrio_add_net() calls device_register() and fails when device_register()fails. Thus, put_device() should be used rather than kfree(). Add"mport->net = NULL;" to avoid a use after free issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked. If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_paramsNull pointer dereference issue could occur when pipe_ctx->plane_stateis null. The fix adds a check to ensure 'pipe_ctx->plane_state' is notnull before accessing. This prevents a null pointer dereference.Found by code review.(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: appleir: Fix potential NULL dereference at raw event handleSyzkaller reports a NULL pointer dereference issue in input_event().BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395Read of size 8 at addr 0000000000000028 by task syz-executor199/2949CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens due to the malformed report items sent by the emulated devicewhich results in a report, that has no fields, being added to the report list.Due to this appleir_input_configured() is never called, hidinput_connect()fails which results in the HID_CLAIMED_INPUT flag is not being set. However,it does not make appleir_probe() fail and lets the event callback to becalled without the associated input device.Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hookearly if the driver didn't claim any input_dev for some reason. Moreover,some other hid drivers accessing input_dev in their event callbacks do havesimilar checks, too.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctlIn the "pmcmd_ioctl" function, three memory objects allocated bykmalloc are initialized by "hcall_get_cpu_state", which are thencopied to user space. The initializer is indeed implemented in"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk ofinformation leakage due to uninitialized bytes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlockThere are multiple places from where the recovery work gets scheduledasynchronously. Also, there are multiple places where the caller waitssynchronously for the recovery to be completed. One such place is duringthe PM shutdown() callback.If the device is not alive during recovery_work, it will try to reset thedevice using pci_reset_function(). This function internally will take thedevice_lock() first before resetting the device. By this time, if the lockhas already been acquired, then recovery_work will get stalled whilewaiting for the lock. And if the lock was already acquired by the callerwhich waits for the recovery_work to be completed, it will lead todeadlock.This is what happened on the X1E80100 CRD device when the device diedbefore shutdown() callback. Driver core calls the driver's shutdown()callback while holding the device_lock() leading to deadlock.And this deadlock scenario can occur on other paths as well, like duringthe PM suspend() callback, where the driver core would hold thedevice_lock() before calling driver's suspend() callback. And if therecovery_work was already started, it could lead to deadlock. This is alsoobserved on the X1E80100 CRD.So to fix both issues, use pci_try_reset_function() in recovery_work. Thisfunction first checks for the availability of the device_lock() beforetrying to reset the device. If the lock is available, it will acquire itand reset the device. Otherwise, it will return -EAGAIN. If that happens,recovery_work will fail with the error message "Recovery failed" as notmuch could be done.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: cleanup mana struct after debugfs_remove()When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),mana_gd_suspend() and mana_gd_resume() are called. If during thismana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfspointer does not get reinitialized and ends up pointing to older,cleaned-up dentry.Further in the hibernation path, as part of power_down(), mana_gd_shutdown()is triggered. This call, unaware of the failures in resume, tries to cleanupthe already cleaned up mana_port_debugfs value and hits the following bug:[ 191.359296] mana 7870:00:00.0: Shutdown was called[ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 191.360584] #PF: supervisor write access in kernel mode[ 191.361125] #PF: error_code(0x0002) - not-present page[ 191.361727] PGD 1080ea067 P4D 0[ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI[ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2[ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 191.364124] RIP: 0010:down_write+0x19/0x50[ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d[ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246[ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000[ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098[ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001[ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000[ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020[ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000[ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0[ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 191.372906] Call Trace:[ 191.373262] [ 191.373621] ? show_regs+0x64/0x70[ 191.374040] ? __die+0x24/0x70[ 191.374468] ? page_fault_oops+0x290/0x5b0[ 191.374875] ? do_user_addr_fault+0x448/0x800[ 191.375357] ? exc_page_fault+0x7a/0x160[ 191.375971] ? asm_exc_page_fault+0x27/0x30[ 191.376416] ? down_write+0x19/0x50[ 191.376832] ? down_write+0x12/0x50[ 191.377232] simple_recursive_removal+0x4a/0x2a0[ 191.377679] ? __pfx_remove_one+0x10/0x10[ 191.378088] debugfs_remove+0x44/0x70[ 191.378530] mana_detach+0x17c/0x4f0[ 191.378950] ? __flush_work+0x1e2/0x3b0[ 191.379362] ? __cond_resched+0x1a/0x50[ 191.379787] mana_remove+0xf2/0x1a0[ 191.380193] mana_gd_shutdown+0x3b/0x70[ 191.380642] pci_device_shutdown+0x3a/0x80[ 191.381063] device_shutdown+0x13e/0x230[ 191.381480] kernel_power_off+0x35/0x80[ 191.381890] hibernate+0x3c6/0x470[ 191.382312] state_store+0xcb/0xd0[ 191.382734] kobj_attr_store+0x12/0x30[ 191.383211] sysfs_kf_write+0x3e/0x50[ 191.383640] kernfs_fop_write_iter+0x140/0x1d0[ 191.384106] vfs_write+0x271/0x440[ 191.384521] ksys_write+0x72/0xf0[ 191.384924] __x64_sys_write+0x19/0x20[ 191.385313] x64_sys_call+0x2b0/0x20b0[ 191.385736] do_syscall_64+0x79/0x150[ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240[ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0[ 191.387124] ? __pfx_lru_add+0x10/0x10[ 191.387515] ? queued_spin_unlock+0x9/0x10[ 191.387937] ? do_anonymous_page+0x33c/0xa00[ 191.388374] ? __handle_mm_fault+0xcf3/0x1210[ 191.388805] ? __count_memcg_events+0xbe/0x180[ 191.389235] ? handle_mm_fault+0xae/0x300[ 19---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acdirmax mount optionUser-provided mount parameter acdirmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acregmax mount optionUser-provided mount parameter acregmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free on hdcp_work[Why]A slab-use-after-free is reported when HDCP is destroyed but theproperty_validate_dwork queue is still running.[How]Cancel the delayed work when destroying workqueue.(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmdAfter the hci sync command releases l2cap_conn, the hci receive data workqueue references the released l2cap_conn when sending to the upper layer.Add hci dev lock to the hci receive data work queue to synchronize the two.[1]BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: hci1 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Bridge, fix the crash caused by LAG state checkWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event istriggered. Driver finds the lower devices (PFs) to flush all theoffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returnsfalse if one of PF is unloaded. In such case,mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead ofthe alive PF, and the flush is skipped.Besides, the bridge fdb entry's lastuse is updated in mlx5 bridgeevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can beignored in this case because the upper interface for bond is deleted,and the entry will never be aged because lastuse is never updated.To make things worse, as the entry is alive, mlx5 bridge workqueuekeeps sending that event, which is then handled by kernel bridgenotifier. It causes the following crash when accessing the passed bondnetdev which is already destroyed.To fix this issue, remove such checks. LAG state is already checked incommit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when addingbond to bridge"), driver still need to skip offload if LAG becomesinvalid state after initialization. Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: handle errors in mlx5_chains_create_table()In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()and mlx5_get_flow_namespace() must be checked to prevent NULL pointerdereferences. If either function fails, the function should log errormessage with mlx5_core_warn() and return error pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/hyperv: Fix address space leak when Hyper-V DRM device is removedWhen a Hyper-V DRM device is probed, the driver allocates MMIO space forthe vram, and maps it cacheable. If the device removed, or in the errorpath for device probing, the MMIO space is released but no unmap is done.Consequently the kernel address space for the mapping is leaked.Fix this by adding iounmap() calls in the device removal path, and in theerror path during device probing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sched: address a potential NULL pointer dereference in the GRED scheduler.If kzalloc in gred_init returns a NULL pointer, the code follows theerror handling path, invoking gred_destroy. This, in turn, callsgred_offload, where memset could receive a NULL pointer as input,potentially leading to a kernel crash.When table->opt is NULL in gred_init(), gred_change_table_def()is not called yet, so it is not necessary to call ->ndo_setup_tc()in gred_offload().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes."Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: ignore non-functional sensor in HP 5MP CameraThe HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface thatis not actually implemented. Attempting to access this non-functionalsensor via iio_info causes system hangs as runtime PM tries to wake upan unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffffAdd this device to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()On the off chance that command stream passed from userspace viaioctl() call to radeon_vce_cs_parse() is weirdly crafted andfirst command to execute is to encode (case 0x03000001), the functionin question will attempt to call radeon_vce_cs_reloc() with sizeargument that has not been properly initialized. Specifically, 'size'will point to 'tmp' variable before the latter had a chance to beassigned any value.Play it safe and init 'tmp' with 0, thus ensuring thatradeon_vce_cs_reloc() will catch an early error in cases like these.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: ucan: fix out of bound read in strscpy() sourceCommit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")unintentionally introduced a one byte out of bound read on strscpy()'ssource argument (which is kind of ironic knowing that strscpy() is meantto be a more secure alternative :)).Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */When doing: strncpy(dest, src, len); dest[len] = '\0';strncpy() will read up to len bytes from src.On the other hand: strscpy(dest, src, len + 1);will read up to len + 1 bytes from src, that is to say, an out of boundread of one byte will occur on src if it is not NUL terminated. Notethat the src[len] byte is never copied, but strscpy() still needs toread it to check whether a truncation occurred or not.This exact pattern happened in ucan.The root cause is that the source is not NUL terminated. Instead ofdoing a copy in a local buffer, directly NUL terminate it as soon asusb_control_msg() returns. With this, the local firmware_str[] variablecan be removed.On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everythingwhen it fails.Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output incase it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in theerror path.Note that we can remove the fib6_nh_release() call in nh_create_ipv6()later in net-next.git.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix error code in chan_alloc_skb_cb()The chan_alloc_skb_cb() function is supposed to return error pointers onerror. Returning NULL will lead to a NULL dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: check that dummy regulator has been probed before using itDue to asynchronous driver probing there is a chance that the dummyregulator hasn't already been probed when first accessing it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup during bt pages loopDriver runs a for-loop when allocating bt pages and mapping them withbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bcAdd a cond_resched() to fix soft lockup during these loops. In order notto affect the allocation performance of normal-size buffer, set the loopcount of a 100GB MR as the threshold to call cond_resched().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pdr: Fix the potential deadlockWhen some client process A call pdr_add_lookup() to add the look up forthe service and does schedule locator work, later a process B got a newserver packet indicating locator is up and call pdr_locator_new_server()which eventually sets pdr->locator_init_complete to true which process Asees and takes list lock and queries domain list but it will timeout dueto deadlock as the response will queued to the same qmi->wq and it isordered workqueue and process B is not able to complete new serverrequest work due to deadlock on list lock.Fix it by removing the unnecessary list iteration as the list iterationis already being done inside locator work, so avoid it here and justcall schedule_work() here. Process A Process B process_scheduled_works()pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret);Timeout error log due to deadlock:" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110"Thanks to Bjorn and Johan for letting me know that this commit also fixesan audio regression when using the in-kernel pd-mapper as that makes iteasier to hit this race. [1]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Fix NULL pointer dereferenceWhen MPOA_cache_impos_rcvd() receives the msg, it can triggerNull Pointer Dereference Vulnerability if both entry andholding_time are NULL. Because there is only for the situationwhere entry is NULL and holding_time exists, it can be passedwhen both entry and holding_time are NULL. If these are NULL,the entry will be passd to eg_cache_put() as parameter andit is referenced by entry->use code in it.kasan log:[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0[ 3.326430] Call Trace:[ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0[ 3.327330] ? exc_general_protection+0x161/0x2a0[ 3.327662] ? asm_exc_general_protection+0x26/0x30[ 3.328214] ? vprintk_emit+0x15e/0x420[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10[ 3.329664] ? console_unlock+0x107/0x1d0[ 3.329946] ? __pfx_console_unlock+0x10/0x10[ 3.330283] ? do_syscall_64+0xa6/0x1a0[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10[ 3.331395] ? down_trylock+0x52/0x80[ 3.331703] ? vprintk_emit+0x15e/0x420[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10[ 3.332279] ? down_trylock+0x52/0x80[ 3.332527] ? _printk+0xbf/0x100[ 3.332762] ? __pfx__printk+0x10/0x10[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10[ 3.333614] msg_from_mpoad+0x1185/0x2750[ 3.333893] ? __build_skb_around+0x27b/0x3a0[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10[ 3.334501] ? __alloc_skb+0x1c0/0x310[ 3.334809] ? __pfx___alloc_skb+0x10/0x10[ 3.335283] ? _raw_spin_lock+0xe0/0xe0[ 3.335632] ? finish_wait+0x8d/0x1e0[ 3.335975] vcc_sendmsg+0x684/0xba0[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10[ 3.337056] ? fdget+0x176/0x3e0[ 3.337348] __sys_sendto+0x4a2/0x510[ 3.337663] ? __pfx___sys_sendto+0x10/0x10[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400[ 3.338364] ? sock_ioctl+0x1bb/0x5a0[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10[ 3.339727] ? selinux_file_ioctl+0xa4/0x260[ 3.340166] __x64_sys_sendto+0xe0/0x1c0[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140[ 3.340898] do_syscall_64+0xa6/0x1a0[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 3.341533] RIP: 0033:0x44a380[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00[ ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: vimc: skip .s_stream() for stopped entitiesSyzbot reported [1] a warning prompted by a check in call_s_stream()that checks whether .s_stream() operation is warranted for unstartedor stopped subdevs.Add a simple fix in vimc_streamer_pipeline_terminate() ensuring thatentities skip a call to .s_stream() unless they have been previouslyproperly started.[1] Syzbot report:------------[ cut here ]------------WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460Modules linked in:CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0...Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2b85c01b19...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: fix narrowing conversion in acpi_nfit_ctlSyzkaller has reported a warning in to_nfit_bus_uuid(): "only secondarybus families can be translated". This warning is emited if the argumentis equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() firstverifies that a user-provided value call_pkg->nd_family of type u64 isnot equal to 0. Then the value is converted to int, and only after thatis compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalidargument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, whilethe lower 32 bits are zero.Furthermore, it is best to return EINVAL immediately upon seeing theinvalid user input. The WARNING is insufficient to prevent furtherundefined behavior based on other invalid user input.All checks of the input value should be applied to the original variablecall_pkg->nd_family.[iweiny: update commit message]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: ibmveth: make veth_pool_store stop hangingv2:- Created a single error handling unlock and exit in veth_pool_store- Greatly expanded commit message with previous explanatory-only textSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,ibmveth_close and ibmveth_open, preventing multiple calls in a row tonapi_disable.Background: Two (or more) threads could call veth_pool_store throughwriting to /sys/devices/vio/30000002/pool*/*. You can do this easilywith a little shell script. This causes a hang.I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a newkernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: add mutual exclusion in proc_sctp_do_udp_port()We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()or risk a crash as syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: imx-card: Add NULL check in imx_card_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,imx_card_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:spufs: fix gang directory lifetimesprior to "[POWERPC] spufs: Fix gang destroy leaks" we used to havea problem with gang lifetimes - creation of a gang returns openedgang directory, which normally gets removed when that gets closed,but if somebody has created a context belonging to that gang andkept it alive until the gang got closed, removal failed and weended up with a leak.Unfortunately, it had been fixed the wrong way. Dentry of gangdirectory was no longer pinned, and rmdir on close was gone.One problem was that failure of open kept calling simple_rmdir()as cleanup, which meant an unbalanced dput(). Another bug wasin the success case - gang creation incremented link count onroot directory, but that was no longer undone when gang gotdestroyed.Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsemof gang directory inode. * having it set to 1 at creation time, droppedin both spufs_dir_close() and spufs_gang_close() and bumpedin spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gangdirectory out when counter reaches zero.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Allocate vfinfo size for VF GUIDs when supportedCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")added support for getting VF port and node GUIDs in netlink ifinfomessages, but their size was not taken into consideration in thefunction that allocates the netlink message, causing the followingwarning when a netlink message is filled with many VF port and nodeGUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too longKernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "smb: client: fix TCP timers deadlock after rmmod"This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock afterrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which ismentioned as CVE-2024-54680, but is actually did not fix anything;The issue can be reproduced on top of it. [0]Also, it reverted the change by commit ef7134c7fc48 ("smb: client:Fix use-after-free of network namespace.") and introduced a realissue by reviving the kernel TCP socket.When a reconnect happens for a CIFS connection, the socket statetransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()in tcp_close() stops all timers for the socket.If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.Usually, FIN can be retransmitted by the peer, but if the peer abortsthe connection, the issue comes into reality.I warned about this privately by pointing out the exact report [1],but the bogus fix was finally merged.So, we should not stop the timers to finally kill the connection onour side in that case, meaning we must not use a kernel socket forTCP whose sk->sk_net_refcnt is 0.The kernel socket does not have a reference to its netns to make itpossible to tear down netns without cleaning up every resource in it.For example, tunnel devices use a UDP socket internally, but we candestroy netns without removing such devices and let it completeduring exit. Otherwise, netns would be leaked when the last applicationdied.However, this is problematic for TCP sockets because TCP has timers toclose the connection gracefully even after the socket is close()d. Thelifetime of the socket and its netns is different from the lifetime ofthe underlying connection.If the socket user does not maintain the netns lifetime, the timer couldbe fired after the socket is close()d and its netns is freed up, resultingin use-after-free.Actually, we have seen so many similar issues and converted such socketsto have a reference to netns.That's why I converted the CIFS client socket to have a reference tonetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scopeof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and rightfix**.Regarding the LOCKDEP issue, we can prevent the module unload bybumping the module refcount when switching the LOCKDDEP key insock_lock_init_class_and_name(). [2]For a while, let's revert the bogus fix.Note that now we can use sk_net_refcnt_upgrade() for the socketconversion, but I'll do so later separately to make backport easy.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpointIf vhost_scsi_set_endpoint is called multiple times without avhost_scsi_clear_endpoint between them, we can hit multiple bugsfound by Haoran Zhang:1. Use-after-free when no tpgs are found:This fixes a use after free that occurs when vhost_scsi_set_endpoint iscalled more than once and calls after the first call do not find anytpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first findstpgs to add to the vs_tpg array match=true, so we will do:vhost_vq_set_backend(vq, vs_tpg);...kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If vhost_scsi_set_endpoint is called again and no tpgs are foundmatch=false so we skip the vhost_vq_set_backend call leaving thepointer to the vs_tpg we then free via:kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If a scsi request is then sent we do:vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backendwhich sees the vs_tpg we just did a kfree on.2. Tpg dir removal hang:This patch fixes an issue where we cannot remove a LIO/target layertpg (and structs above it like the target) dir due to the refcountdropping to -1.The problem is that if vhost_scsi_set_endpoint detects a tpg is alreadyin the vs->vs_tpg array or if the tpg has been removed sotarget_depend_item fails, the undepend goto handler will dotarget_undepend_item on all tpgs in the vs_tpg array dropping theirrefcount to 0. At this time vs_tpg contains both the tpgs we have addedin the current vhost_scsi_set_endpoint call as well as tpgs we added inprevious calls which are also in vs->vs_tpg.Later, when vhost_scsi_clear_endpoint runs it will dotarget_undepend_item on all the tpgs in the vs->vs_tpg which will droptheir refcount to -1. Userspace will then not be able to remove the tpgand will hang when it tries to do rmdir on the tpg dir.3. Tpg leak:This fixes a bug where we can leak tpgs and cause them to beun-removable because the target name is overwritten whenvhost_scsi_set_endpoint is called multiple times but with differenttarget names.The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setupa vhost-scsi device to target/tpg mapping, then callsVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs wehaven't seen before (target1 has tpg1 but target2 has tpg2). When thishappens we don't teardown the old target tpg mapping and just overwritethe target name and the vs->vs_tpg array. Later when we dovhost_scsi_clear_endpoint, we are passed in either target1 or target2'sname and we will only match that target's tpgs when we loop over thevs->vs_tpg. We will then return from the function without doingtarget_undepend_item on the tpgs.Because of all these bugs, it looks like being able to callvhost_scsi_set_endpoint multiple times was never supported. The majoruser, QEMU, already has checks to prevent this use case. So to fix theissues, this patch prevents vhost_scsi_set_endpoint from being calledif it's already successfully added tpgs. To add, remove or change thetpg config or target name, you must do a vhost_scsi_clear_endpointfirst.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flowWhen cur_qp isn't NULL, in order to avoid fetching the QP fromthe radix tree again we check if the next cqe QP is identical tothe one we already have.The bug however is that we are checking if the QP is identical bychecking the QP number inside the CQE against the QP number inside themlx5_ib_qp, but that's wrong since the QP number from the CQE is fromFW so it should be matched against mlx5_core_qp which is our FW QPnumber.Otherwise we could use the wrong QP when handling a CQE which couldcause the kernel trace below.This issue is mainly noticeable over QPs 0 & 1, since for now they arethe only QPs in our driver whereas the QP number inside mlx5_ib_qpdoesn't match the QP number inside mlx5_core_qp.BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()If track_pfn_copy() fails, we already added the dst VMA to the mapletree. As fork() fails, we'll cleanup the maple tree, and stumble overthe dst VMA for which we neither performed any reservation nor copiedany page tables.Consequently untrack_pfn() will see VM_PAT and try obtaining thePAT information from the page table -- which fails because the pagetable was not copied.The easiest fix would be to simply clear the VM_PAT flag of the dst VMAif track_pfn_copy() fails. However, the whole thing is about "simply"clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()and performed a reservation, but copying the page tables fails, we'llsimply clear the VM_PAT flag, not properly undoing the reservation ...which is also wrong.So let's fix it properly: set the VM_PAT flag only if the reservationsucceeded (leaving it clear initially), and undo the reservation ifanything goes wrong while copying the page tables: clearing the VM_PATflag after undoing the reservation.Note that any copied page table entries will get zapped when the VMA willget removed later, after copy_page_range() succeeded; as VM_PAT is not setthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will behappy. Note that leaving these page tables in place without a reservationis not a problem, as we are aborting fork(); this process will never run.A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")... and instead of undoing the reservation we simply cleared the VM_PAT flag.Keep the documentation of these functions in include/linux/pgtable.h,one place is more than sufficient -- we should clean that up for the otherfunctions like track_pfn_remap/untrack_pfn separately.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Remove broken autobindBinding AX25 socket by using the autobind feature leads to memory leaksin ax25_connect() and also refcount leaks in ax25_release(). Memoryleak was detected with kmemleak:================================================================unreferenced object 0xffff8880253cd680 (size 96):backtrace:__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)kmemdup_noprof (mm/util.c:136)ax25_rt_autobind (net/ax25/ax25_route.c:428)ax25_connect (net/ax25/af_ax25.c:1282)__sys_connect_file (net/socket.c:2045)__sys_connect (net/socket.c:2064)__x64_sys_connect (net/socket.c:2067)do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)================================================================When socket is bound, refcounts must be incremented the way it is donein ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case ofautobind, the refcounts are not incremented.This bug leads to the following issue reported by Syzkaller:================================================================ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de------------[ cut here ]------------refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31Modules linked in:CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31...Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Considering the issues above and the comments left in the code that say:"check if we can remove this feature. It is broken."; "autobinding in thismay or may not work"; - it is better to completely remove this feature thanto fix it because it is broken and leads to various kinds of memory bugs.Now calling connect() without first binding socket will result in anerror (-EINVAL). Userspace software that relies on the autobind featuremight get broken. However, this feature does not seem widely used withthis specific driver as it was not reliable at any point of time, and itis already broken anyway. E.g. ax25-tools and ax25-apps packages forpopular distributions do not use the autobind feature for AF_AX25.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1,raid10: don't ignore IO flagsIf blk-wbt is enabled by default, it's found that raid write performanceis quite bad because all IO are throttled by wbt of underlying disks,due to flag REQ_IDLE is ignored. And turns out this behaviour exist sinceblk-wbt is introduced.Other than REQ_IDLE, other flags should not be ignored as well, forexample REQ_META can be set for filesystems, clearing it can cause priorityreverse problems; And REQ_NOWAIT should not be cleared as well, becauseio will wait instead of failing directly in underlying disks.Fix those problems by keep IO flags from master bio.Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: int340x: Add NULL check for adevNot all devices have an ACPI companion fwnode, so adev might be NULL.This is similar to the commit cd2fd6eab480("platform/x86: int3472: Check for adev == NULL").Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in int3402_thermal_probe().Note, under the same directory, int3400_thermal_probe() has such acheck.[ rjw: Subject edit, added Fixes: ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq errorAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQshave been released.However, some requested IRQs remain unreleased, so there are still/proc/irq/* entries remaining, and this results in WARN() with thefollowing message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19cTo solve this issue, set the number of remaining IRQs to test->num_irqs,and release IRQs in advance by calling pci_endpoint_test_release_irq().[kwilczynski: commit log]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: detect and prevent references to a freed transport in sendmsgsctp_sendmsg() re-uses associations and transports when possible bydoing a lookup based on the socket endpoint and the message destinationaddress, and then sctp_sendmsg_to_asoc() sets the selected transport inall the message chunks to be sent.There's a possible race condition if another thread triggers the removalof that selected transport, for instance, by explicitly unbinding anaddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks havebeen set up and before the message is sent. This can happen if the sendbuffer is full, during the period when the sender thread temporarilyreleases the socket lock in sctp_wait_for_sndbuf().This causes the access to the transport data insctp_outq_select_transport(), when the association outqueue is flushed,to result in a use-after-free read.This change avoids this scenario by having sctp_transport_free() signalthe freeing of the transport, tagging it as "dead". In order to do this,the patch restores the "dead" bit in struct sctp_transport, which wasremoved incommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").Then, in the scenario where the sender thread has released the socketlock in sctp_wait_for_sndbuf(), the bit is checked again afterre-acquiring the socket lock to detect the deletion. This is done whileholding a reference to the transport to prevent it from being freed inthe process.If the transport was deleted while the socket lock was relinquished,sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry thesend.The bug was found by a private syzbot instance (see the error report [1]and the C reproducer that triggers it [2]).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.When I ran the repro [0] and waited a few seconds, I observed twoLOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables ruleAt step 3), the CIFS module calls sock_release() for the underlyingTCP socket, and it returns quickly. However, the socket remains inFIN_WAIT_1 because incoming FIN packets are dropped.At this point, the module's refcnt is 0 while the socket is stillalive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0This highlights a discrepancy between the lifetime of the CIFS moduleand the underlying TCP socket. Even after CIFS calls sock_release()and it returns, the TCP socket does not die immediately in order toclose the connection gracefully.While this is generally fine, it causes an issue with LOCKDEP becauseCIFS assigns a different lock class to the TCP socket's sk->sk_lockusing sock_lock_init_class_and_name().Once an incoming packet is processed for the socket or a timer fires,sk->sk_lock is acquired.Then, LOCKDEP checks the lock context in check_wait_context(), wherehlock_class() is called to retrieve the lock class. However, sincethe module has already been unloaded, hlock_class() logs a warningand returns NULL, triggering the null-ptr-deref.If LOCKDEP is enabled, we must ensure that a module callingsock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloadedwhile such a socket is still alive to prevent this issue.Let's hold the module reference in sock_lock_init_class_and_name()and release it when the socket is freed in sk_prot_free().Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()that calls sock_lock_init_class_and_name() for a listening socket,which clones a socket by sk_clone_lock() without GFP_ZERO.[0]:CIFS_SERVER="10.0.0.137"CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"DEV="enp0s3"CRED="/root/WindowsCredential.txt"MNT=$(mktemp -d /tmp/XXXXXX)mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1iptables -A INPUT -s ${CIFS_SERVER} -j DROPfor i in $(seq 10);do umount ${MNT} rmmod cifs sleep 1donerm -r ${MNT}iptables -D INPUT -s ${CIFS_SERVER} -j DROP[1]:DEBUG_LOCKS_WARN_ON(1)WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)...Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)...BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36Tainted: [W]=WARNHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__lock_acquire (kernel/---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: ene-kb3930: Fix a potential NULL pointer dereferenceThe off_gpios could be NULL. Add missing check in the kb3930_probe().This is similar to the issue fixed in commit b1ba8bcb2d1f("backlight: hx8357: Fix potential NULL pointer dereference").This was detected by our static analysis tool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: Add NULL pointer check in i3c_master_queue_ibi()The I3C master driver may receive an IBI from a target device that has notbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`to queue an IBI work task, leading to "Unable to handle kernel read fromunreadable memory" and resulting in a kernel panic.Typical IBI handling flow:1. The I3C master scans target devices and probes their respective drivers.2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`.3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver's IBI handler task.However, since target device events are asynchronous to the I3C probesequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,leading to a kernel panic.Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessingan uninitialized `dev->ibi`, ensuring stability.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()soc_dev_attr->revision could be NULL, thus,a pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix off-by-one error in do_splitSyzkaller detected a use-after-free issue in ext4_insert_dentry that wascaused by out-of-bounds access due to incorrect splitting in do_split.BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement.for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++;}'i' in this case could go down to -1, in which case sum of active entrieswouldn't exceed half the block size, but previous behaviour would also dosplit in half if sum would exceed at the very last block, which in case ofhaving too many long name files in a single block could lead toout-of-bounds access and following use-after-free.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: refactor hfi packet parsing logicwords_count denotes the number of words in total payload, while datapoints to payload of various property within it. When words_countreaches last word, data can access memory beyond the total payload. Thiscan lead to OOB access. With this patch, the utility api for handlingindividual properties now returns the size of data consumed. Accordinglyremaining bytes are calculated before parsing the payload, therebyeliminates the OOB access possibilities.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: add check to avoid out of bound accessThere is a possibility that init_codecs is invoked multiple times duringmanipulated payload from video firmware. In such case, if codecs_countcan get incremented to value more than MAX_CODEC_NUM, there can be OOBaccess. Reset the count so that it always starts from beginning.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add check to handle incorrect queue sizeqsize represents size of shared queued between driver and videofirmware. Firmware can modify this value to an invalid large value. Insuch situation, empty_space will be bigger than the space actuallyavailable. Since new_wr_idx is not checked, so the following code willresult in an OOB write....qsize = qhdr->q_sizeif (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx)....if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB writeAdd check to ensure qsize is within the allocated size whilereading and writing packets into the queue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add a check to handle OOB in sfr regionsfr->buf_size is in shared memory and can be modified by malicious user.OOB write is possible when the size is made higher than actual sfr databuffer. Cap the size to allocated size for such cases.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t typeThe access to the PCI config space via pci_ops::read and pci_ops::write isa low-level hardware access. The functions can be accessed with disabledinterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for thispurpose.A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot beacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed inthe same context as the pci_lock.Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used withinterrupts disabled.This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90[bigeasy: reword commit message]Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log][bhelgaas: add back report info fromhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: don't propagate flags on openWith the device instance lock, there is now a possibility of a deadlock:[ 1.211455] ============================================[ 1.211571] WARNING: possible recursive locking detected[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted[ 1.211823] --------------------------------------------[ 1.211936] ip/184 is trying to acquire lock:[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0[ 1.212207][ 1.212207] but task is already holding lock:[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.212487][ 1.212487] other info that might help us debug this:[ 1.212626] Possible unsafe locking scenario:[ 1.212626][ 1.212751] CPU0[ 1.212815] ----[ 1.212871] lock(&dev->lock);[ 1.212944] lock(&dev->lock);[ 1.213016][ 1.213016] *** DEADLOCK ***[ 1.213016][ 1.213143] May be due to missing lock nesting notation[ 1.213143][ 1.213294] 3 locks held by ip/184:[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.213895][ 1.213895] stack backtrace:[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014[ 1.213994] Call Trace:[ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0[ 1.214000] print_deadlock_bug+0x28b/0x2a0[ 1.214020] lock_acquire+0xea/0x2a0[ 1.214027] __mutex_lock+0xbf/0xd40[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev[ 1.214042] __dev_open+0x145/0x270[ 1.214046] __dev_change_flags+0xb0/0x1e0[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0[ 1.214058] notifier_call_chain+0x78/0x120[ 1.214062] netif_open+0x6d/0x90[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0[ 1.214066] bond_enslave+0x64c/0x1230[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0[ 1.214077] do_setlink+0x516/0x13b0[ 1.214094] rtnl_newlink+0xaba/0xb80[ 1.214132] rtnetlink_rcv_msg+0x440/0x490[ 1.214144] netlink_rcv_skb+0xeb/0x120[ 1.214150] netlink_unicast+0x1f9/0x320[ 1.214153] netlink_sendmsg+0x346/0x3f0[ 1.214157] __sock_sendmsg+0x86/0xb0[ 1.214160] ____sys_sendmsg+0x1c8/0x220[ 1.214164] ___sys_sendmsg+0x28f/0x2d0[ 1.214179] __x64_sys_sendmsg+0xef/0x140[ 1.214184] do_syscall_64+0xec/0x1d0[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 1.214191] RIP: 0033:0x7f2d1b4a7e56Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down)When we enslave the lower device (netdevsim0) which has a vlan, wepropagate vlan's allmuti/promisc flags during ndo_open. This causes(re)locking on of the real_dev.Propagate allmulti/promisc on flags change, not on the open. Thereis a slight semantics change that vlans that are down now propagatethe flags, but this seems unlikely to result in the real issues.Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: ignore xattrs past endOnce inside 'ext4_xattr_inode_dec_ref_all' we shouldignore xattrs entries past the 'end' entry.This fixes the following KASAN reported issue:==================================================================BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90Read of size 4 at addr ffff888012c120c4 by task repro/2065CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x1fd/0x300 ? tcp_gro_dev_warn+0x260/0x260 ? _printk+0xc0/0x100 ? read_lock_is_recursive+0x10/0x10 ? irq_work_queue+0x72/0xf0 ? __virt_addr_valid+0x17b/0x4b0 print_address_description+0x78/0x390 print_report+0x107/0x1f0 ? __virt_addr_valid+0x17b/0x4b0 ? __virt_addr_valid+0x3ff/0x4b0 ? __phys_addr+0xb5/0x160 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 kasan_report+0xcc/0x100 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ? ext4_xattr_delete_inode+0xd30/0xd30 ? __ext4_journal_ensure_credits+0x5f0/0x5f0 ? __ext4_journal_ensure_credits+0x2b/0x5f0 ? inode_update_timestamps+0x410/0x410 ext4_xattr_delete_inode+0xb64/0xd30 ? ext4_truncate+0xb70/0xdc0 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20 ? __ext4_mark_inode_dirty+0x670/0x670 ? ext4_journal_check_start+0x16f/0x240 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0 ext4_evict_inode+0xc8c/0xff0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 ? do_raw_spin_unlock+0x53/0x8a0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? proc_nr_inodes+0x310/0x310 ? trace_ext4_drop_inode+0xa2/0x220 ? _raw_spin_unlock+0x1a/0x30 ? iput+0x4cb/0x7e0 do_unlinkat+0x495/0x7c0 ? try_break_deleg+0x120/0x120 ? 0xffffffff81000000 ? __check_object_size+0x15a/0x210 ? strncpy_from_user+0x13e/0x250 ? getname_flags+0x1dc/0x530 __x64_sys_unlinkat+0xc8/0xf0 do_syscall_64+0x65/0x110 entry_SYSCALL_64_after_hwframe+0x67/0x6fRIP: 0033:0x434ffdCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffdRDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 The buggy address belongs to the object at ffff888012c12000 which belongs to the cache filp of size 360The buggy address is located 196 bytes inside of freed 360-byte region [ffff888012c12000, ffff888012c12168)The buggy address belongs to the physical page:page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0flags: 0x40(head|node=0|zone=0)page_type: f5(slab)raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb> ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888012c12180: fc fc fc fc fc fc fc fc fc---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in decryption with multichannelAfter commit f7025d861694 ("smb: client: allocate crypto only forprimary server") and commit b0abcd65ec54 ("smb: client: fix UAF inasync decryption"), the channels started reusing AEAD TFM from primarychannel to perform synchronous decryption, but that can't done asthere could be multiple cifsd threads (one per channel) simultaneouslyaccessing it to perform decryption.This fixes the following KASAN splat when running fstest generic/249with 'vers=3.1.1,multichannel,max_channels=4,seal' against WindowsServer 2022:BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110Read of size 8 at addr ffff8881046c18a0 by task cifsd/986CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: explicitly disallow disconnectsyzbot discovered that it can disconnect a TLS socket and thenrun into all sort of unexpected corner cases. I have a vaguerecollection of Eric pointing this out to us a long time ago.Supporting disconnect is really hard, for one thing if offloadis enabled we'd need to wait for all packets to be _acked_.Disconnect is not commonly used, disallow it.The immediate problem syzbot run into is the warning in the strp,but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix memory leak in tipc_link_xmitIn case the backlog transmit queue for system-importance messages is overloaded,tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads tomemory leak and failure when a skb is allocated.This commit fixes this issue by purging the skb list before tipc_link_xmit()returns.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix ttm_bo_delayed_delete oopsFix an oops in ttm_bo_delayed_delete which results from dererencing adangling pointer:Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMPCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024Workqueue: ttm ttm_bo_delayed_delete [ttm]RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8bRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6bR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383ccFS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is:- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo.- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo.- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete.- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.Fix this by moving the drm_prime_gem_destroy call fromnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it willbe run after ttm_bo_delayed_delete.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: add filesystem context source name checkIn certain scenarios, for example, during fuzz testing, the sourcename may be NULL, which could lead to a kernel panic. Therefore, anextra check for the source name should be added.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Prevent the use of too small fidsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]The handle_bytes value passed in by the reproducing program is equal to 12.In handle_to_path(), only 12 bytes of memory are allocated for the structurefile_handle->f_handle member, which causes an out-of-bounds access whenaccessing the member parent_block of the structure isofs_fid in isofs,because accessing parent_block requires at least 16 bytes of f_handle.Here, fh_len is used to indirectly confirm that the value of handle_bytesis greater than 3 before accessing parent_block.[1]BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cros-ec-tunnel: defer probe if parent EC is not presentWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parentdevice will not be found, leading to NULL pointer dereference.That can also be reproduced by unbinding the controller driver and thenloading i2c-cros-ec-tunnel module (or binding the device).[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058[ 271.998215] #PF: supervisor read access in kernel mode[ 272.003351] #PF: error_code(0x0000) - not-present page[ 272.008485] PGD 0 P4D 0[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel][ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0[ 272.129155] Call Trace:[ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110[ 272.137985] platform_probe+0x69/0xa0[ 272.141652] really_probe+0x152/0x310[ 272.145318] __driver_probe_device+0x77/0x110[ 272.149678] driver_probe_device+0x1e/0x190[ 272.153864] __driver_attach+0x10b/0x1e0[ 272.157790] ? driver_attach+0x20/0x20[ 272.161542] bus_for_each_dev+0x107/0x150[ 272.165553] bus_add_driver+0x15d/0x270[ 272.169392] driver_register+0x65/0x110[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698][ 272.182617] do_one_initcall+0x110/0x350[ 272.186543] ? security_kernfs_init_security+0x49/0xd0[ 272.191682] ? __kernfs_new_node+0x1b9/0x240[ 272.195954] ? security_kernfs_init_security+0x49/0xd0[ 272.201093] ? __kernfs_new_node+0x1b9/0x240[ 272.205365] ? kernfs_link_sibling+0x105/0x130[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0[ 272.214773] ? kernfs_activate+0x57/0x70[ 272.218699] ? kernfs_add_one+0x118/0x160[ 272.222710] ? __kernfs_create_file+0x71/0xa0[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110[ 272.232033] ? internal_create_group+0x453/0x4a0[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0[ 272.241355] ? __free_frozen_pages+0x1dc/0x420[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0[ 272.250505] ? load_module+0x1509/0x16f0[ 272.254431] do_init_module+0x60/0x230[ 272.258181] __se_sys_finit_module+0x27a/0x370[ 272.262627] do_syscall_64+0x6a/0xf0[ 272.266206] ? do_syscall_64+0x76/0xf0[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 272.279887] RIP: 0033:0x7b9309168d39[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After "complete" becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree'sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user's PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registeredRussell King reports that a system with mv88e6xxx dereferences a NULLpointer when unbinding this driver:https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/The crash seems to be in devlink_region_destroy(), which is not NULLtolerant but is given a NULL devlink global region pointer.At least on some chips, some devlink regions are conditionally registeredsince the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue;These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chipdoes not have an STU or PVT, it should crash like this.To fix the issue, avoid unregistering those regions which are NULL, i.e.were skipped at mv88e6xxx_setup_devlink_regions_global() time.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error pathIn the for loop used to allocate the loc_array and bmap for each port, amemory leak is possible when the allocation for loc_array succeeds,but the allocation for bmap fails. This is because when the control flowgoes to the label free_eth_finfo, only the allocations starting from(i-1)th iteration are freed.Fix that by freeing the loc_array in the bmap allocation error path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btrtl: Prevent potential NULL dereferenceThe btrtl_initialize() function checks that rtl_load_file() eitherhad an error or it loaded a zero length file. However, if it loadeda zero length file then the error code is not set correctly. Itresults in an error pointer vs NULL bug, followed by a NULL pointerdereference. This was detected by Smatch:drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Purge vif txq in ieee80211_do_stop()After ieee80211_do_stop() SKB from vif's txq could still be processed.Indeed another concurrent vif schedule_and_wake_txq call could causethose packets to be dequeued (see ieee80211_handle_wake_tx_queue())without checking the sdata current state.Because vif.drv_priv is now cleared in this function, this could lead todriver crash.For example in ath12k, ahvif is store in vif.drv_priv. Thus ifath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can beNULL, leading the ath12k_warn(ahvif->ah,...) call in this function totrigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158To avoid that, empty vif's txq at ieee80211_do_stop() so no packet couldbe dequeued after ieee80211_do_stop() (new packets cannot be queuedbecause SDATA_STATE_RUNNING is cleared at this point).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: at76c50x: fix use after free access in at76_disconnectThe memory pointed to by priv is freed at the end of at76_delete_devicefunction (using ieee80211_free_hw). But the code then accesses the udevfield of the freed object to put the USB device. This may also lead to amemory leak of the usb device. Fix this by using udev from interface.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:udmabuf: fix a buf size overflow issue during udmabuf creationby casting size_limit_mb to u64 when calculate pglimit.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mcb: fix a double free bug in chameleon_parse_gdd()In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'would be released in mcb_device_register() via put_device().Thus, goto 'err' label and free 'mdev' again causes a double free.Just return if mcb_device_register() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()With ACPI in place, gicv2m_get_fwnode() is registered with the pcisubsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtimeduring a PCI host bridge probe. But, the call back is wrongly marked as__init, causing it to be freed, while being registered with the PCIsubsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548This is easily reproducible on a Juno board with ACPI boot.Retain the function for later use.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()The function xdp_convert_buff_to_frame() may return NULL if it failsto correctly convert the XDP buffer into an XDP frame due to memoryconstraints, internal errors, or invalid data. Failing to check for NULLmay lead to a NULL pointer dereference if the result is used later inprocessing, potentially causing crashes, data corruption, or undefinedbehavior.On XDP redirect failure, the associated page must be released explicitlyif it was previously retained via get_page(). Failing to do so may resultin a memory leak, as the pages reference count is not decremented.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix NULL pointer dereference in tipc_mon_reinit_self()syzbot reported:tipc: Node number set to 1055423674Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: events tipc_net_finalize_workRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ...RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400There is a racing condition between workqueue created when enablingbearer and another thread created when disabling bearer right afterthat as follow:enabling_bearer | disabling_bearer--------------- | ----------------tipc_disc_timeout() |{ | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | {} | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | }tipc_net_finalize_work() | }{ | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scpi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scmi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reference leak in pci_register_host_bridge()If device_register() fails, call put_device() to give up the reference toavoid a memory leak, per the comment at device_register().Found by code review.[bhelgaas: squash Dan Carpenter's double free fix fromhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: fix PM resume warningFixed warning on PM resume as shown below caused due to uninitializedstruct nand_operation that checks chip select field :WARN_ON(op->cs >= nanddev_ntargets(&chip->base)[ 14.588522] ------------[ cut here ]------------[ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8[ 14.588553] Modules linked in: bdc udc_core[ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16[ 14.588590] Tainted: [W]=WARN[ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree)[ 14.588598] Call trace:[ 14.588604] dump_backtrace from show_stack+0x18/0x1c[ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c[ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c[ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c[ 14.588653] r5:c08d40b0 r4:c1003cb0[ 14.588656] dump_stack from __warn+0x84/0xe4[ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194[ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000[ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8[ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048[ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150[ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040[ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54[ 14.588735] r5:00000010 r4:c0840a50[ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c[ 14.588757] dpm_run_callback from device_resume+0xc0/0x324[ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010[ 14.588779] device_resume from dpm_resume+0x130/0x160[ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0[ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20[ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414[ 14.588826] r4:00000010[ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8[ 14.588848] r5:c228a414 r4:00000000[ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc[ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000[ 14.588871] r4:00000003[ 14.588874] pm_suspend from state_store+0x74/0xd0[ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003[ 14.588892] state_store from kobj_attr_store+0x1c/0x28[ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250[ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c[ 14.588936] r5:c3502900 r4:c0d92a48[ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0[ 14.588956] r5:c3502900 r4:c3501f40[ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420[ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00[ 14.588983] r4:c042a88c[ 14.588987] vfs_write from ksys_write+0x74/0xe4[ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00[ 14.589008] r4:c34f7f00[ 14.589011] ksys_write from sys_write+0x10/0x14[ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004[ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c[ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)[ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001[ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78[ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8[ 14.589065] ---[ end trace 0000000000000000 ]---The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, whendoing PM resume operation in compliance with the controller support for singledie nand chip. Switching from nand_reset_op() to nan---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl-qspi: use devm function instead of driver removeDriver use devm APIs to manage clk/irq/resources and register the spicontroller, but the legacy remove function will be called first duringdevice detach and trigger kernel panic. Drop the remove function and usedevm_add_action_or_reset() for driver cleanup to ensure the releasesequence.Trigger kernel panic on i.MX8MQ byecho 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: avoid NULL pointer dereference in dbg callcifs_server_dbg() implies server to be non-NULL somove call under condition to avoid NULL pointer dereference.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has adivide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()returns zero.This is presumably just a theoretical problem: COMPILE_TEST overridesthe dependency on RALINK which would select COMMON_CLK. Regardless it'sa good idea to check for the error explicitly to avoid divide-by-zero.Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()Add error handling to propagate amdgpu_cgs_create_device() failuresto the caller. When amdgpu_cgs_create_device() fails, release hwmgrand return -ENOMEM to prevent null pointer dereference.[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: debugfs hang_hws skip GPU with MESdebugfs hang_hws is used by GPU reset test with HWS, for MES this crashthe kernel with NULL pointer access because dqm->packet_mgr is not setupfor MES path.Skip GPU with MES for now, MES hang_hws debugfs interface will besupported later.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: pidff: Fix null pointer dereference in pidff_find_fieldsThis function triggered a null pointer dereference if used to search fora report that isn't implemented on the device. This happened both foroptional and required reports alike.The same logic was applied to pidff_find_special_field and althoughpidff_init_fields should return an error earlier if one of the requiredreports is missing, future modifications could change this logic andresurface this possible null pointer dereference again.LKML bug report:https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Silence oversized kvmalloc() warningsyzkaller triggered an oversized kvmalloc() warning.Silence it by adding __GFP_NOWARN.syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:igc: fix PTM cycle trigger logicWriting to clear the PTM status 'valid' bit while the PTM cycle istriggered results in unreliable PTM operation. To fix this, clear thePTM 'trigger' and status after each PTM transaction.The issue can be reproduced with the following:$ sudo phc2sys -R 1000 -O 0 -i tsn0 -mNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way toquickly reproduce the issue.PHC2SYS exits with:"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction failsThis patch also fixes a hang in igc_probe() when loading the igcdriver in the kdump kernel on systems supporting PTM.The igc driver running in the base kernel enables PTM trigger inigc_probe(). Therefore the driver is always in PTM trigger mode,except in brief periods when manually triggering a PTM cycle.When a crash occurs, the NIC is reset while PTM trigger is enabled.Due to a hardware problem, the NIC is subsequently in a bad busmasterstate and doesn't handle register reads/writes. When runningigc_probe() in the kdump kernel, the first register access to a NICregister hangs driver probing and ultimately breaks kdump.With this patch, igc has PTM trigger disabled most of the time,and the trigger is only enabled for very brief (10 - 100 us) periodswhen manually triggering a PTM cycle. Chances that a crash occursduring a PTM trigger are not 0, but extremely reduced.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix WARN_ON(!ctx) in __free_event() for partial initMove the get_ctx(child_ctx) call and the child_event->ctx assignment tooccur immediately after the child event is allocated. Ensure thatchild_event->ctx is non-NULL before any subsequent error path withininherit_event calls free_event(), satisfying the assumptions of thecleanup code.Details:There's no clear Fixes tag, because this bug is a side-effect ofmultiple interacting commits over time (up to 15 years old), nota single regression.The code initially incremented refcount then assigned contextimmediately after the child_event was created. Later, an earlyvalidity check for child_event was added before therefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check wasadded, assuming event->ctx is valid if the pmu_ctx is valid.The problem is that the WARN_ON_ONCE() could trigger after the initialcheck passed but before child_event->ctx was assigned, violating itsprecondition. The solution is to assign child_event->ctx right afterits initial validation. This ensures the context exists for anysubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().To resolve it, defer the refcount update and child_event->ctx assignmentdirectly after child_event->pmu_ctx is set but before checking if theparent event is orphaned. The cleanup routine depends onevent->pmu_ctx being non-NULL before it verifies event->ctx isnon-NULL. This also maintains the author's original intent of passingin child_ctx to find_get_pmu_context before its refcount/assignment.[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:9p/net: fix improper handling of bogus negative read/write repliesIn p9_client_write() and p9_client_read_once(), if the serverincorrectly replies with success but a negative write/read count then wewould consider written (negative) <= rsize (positive) because bothvariables were signed.Make variables unsigned to avoid this problem.The reproducer linked below now fails with the following error insteadof a null pointer deref:9pnet: bogus RWRITE count (4294967295 > 3)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()The variable d->name, returned by devm_kasprintf(), could be NULL.A pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: qfq: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of qfq, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.This patch checks whether the class was already added to the agg->activelist (cl_is_active) before doing the addition to cater for the reentrantcase.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of ets, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whetherthe class was already added to the active_list (cl_is_active) beforedoing the addition to cater for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: drr: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of drr, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whether theclass was already added to the active_list (cl_is_active) before addingto the list to cover for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: adjust subpage bit start based on sectorsizeWhen running machines with 64k page size and a 16k nodesize we startedseeing tree log corruption in production. This turned out to be becausewe were not writing out dirty blocks sometimes, so this in fact affectsall metadata writes.When writing out a subpage EB we scan the subpage bitmap for a dirtyrange. If the range isn't dirty we do bit_start++;to move onto the next bit. The problem is the bitmap is based on thenumber of sectors that an EB has. So in this case, we have a 64kpagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4bits for every node. With a 64k page size we end up with 4 nodes perpage.To make this easier this is how everything looks[0 16k 32k 48k ] logical address[0 4 8 12 ] radix tree offset[ 64k page ] folio[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers[ | | | | | | | | | | | | | | | | ] bitmapNow we use all of our addressing based on fs_info->sectorsize_bits, soas you can see the above our 16k eb->start turns into radix entry 4.When we find a dirty range for our eb, we correctly do bit_start +=sectors_per_node, because if we start at bit 0, the next bit for thenext eb is 4, to correspond to eb->start 16k.However if our range is clean, we will do bit_start++, which will nowput us offset from our radix tree entries.In our case, assume that the first time we check the bitmap the block isnot dirty, we increment bit_start so now it == 1, and then we looparound and check again. This time it is dirty, and we go to find thatstart using the following equation start = folio_start + bit_start * fs_info->sectorsize;so in the case above, eb->start 0 is now dirty, and we calculate startas 0 + 1 * fs_info->sectorsize = 4096 4096 >> 12 = 1Now we're looking up the radix tree for 1, and we won't find an eb.What's worse is now we're using bit_start == 1, so we do bit_start +=sectors_per_node, which is now 5. If that eb is dirty we will run intothe same thing, we will look at an offset that is not populated in theradix tree, and now we're skipping the writeout of dirty extent buffers.The best fix for this is to not use sectorsize_bits to address nodes,but that's a larger change. Since this is a fs corruption problem fixit simply by always using sectors_per_node to increment the start bit.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()If dib8000_set_dds()'s call to dib8000_read32() returns zero, the resultis a divide-by-zero. Prevent that from happening.Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Verify event formats that have "%*p.."The trace event verifier checks the formats of trace events to make surethat they do not point at memory that is not in the trace event itself orin data that will never be freed. If an event references data that wasallocated when the event triggered and that same data is freed before theevent is read, then the kernel can crash by reading freed memory.The verifier runs at boot up (or module load) and scans the print formatsof the events and checks their arguments to make sure that dereferencedpointers are safe. If the format uses "%*p.." the verifier will ignore it,and that could be dangerous. Cover this case as well.Also add to the sample code a use case of "%*pbl".

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Add cond_resched() to ftrace_graph_set_hash()When the kernel contains a large number of functions that can be traced,the loop in ftrace_graph_set_hash() may take a lot of time to execute.This may trigger the softlockup watchdog.Add cond_resched() within the loop to allow the kernel to remainresponsive even when processing a large number of functions.This matches the cond_resched() that is used in other locations of thecode that iterates over all functions that can be traced.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHYDSA has 2 kinds of drivers:1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz2. Those who don't: all others. The above methods should be optional.For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),and dsa_switch_resume() calls dsa_user_resume() -> phylink_start().These seem good candidates for setting mac_managed_pm = true becausethat is essentially its definition [1], but that does not seem to be thebiggest problem for now, and is not what this change focuses on.Talking strictly about the 2nd category of DSA drivers here (whichdo not have MAC managed PM, meaning that for their attached PHYs,mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),I have noticed that the following warning from mdio_bus_phy_resume() istriggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP);because the PHY state machine is running.It's running as a result of a previous dsa_user_open() -> ... ->phylink_start() -> phy_start() having been initiated by the user.The previous mdio_bus_phy_suspend() was supposed to have calledphy_stop_machine(), but it didn't. So this is why the PHY is in statePHY_NOLINK by the time mdio_bus_phy_resume() runs.mdio_bus_phy_suspend() did not call phy_stop_machine() because forphylink, the phydev->adjust_link function pointer is NULL. This seems atechnicality introduced by commit fddd91016d16 ("phylib: fix PAL statemachine restart on resume"). That commit was written before phylinkexisted, and was intended to avoid crashing with consumer drivers whichdon't use the PHY state machine - phylink always does, when using a PHY.But phylink itself has historically not been developed withsuspend/resume in mind, and apparently not tested too much in thatscenario, allowing this bug to exist unnoticed for so long. Plus, priorto the WARN_ON(), it would have likely been invisible.This issue is not in fact restricted to type 2 DSA drivers (according tothe above ad-hoc classification), but can be extrapolated to any MACdriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just wherethe issue was reported. Assuming mac_managed_pm is set correctly, aquick search indicates the following other drivers might be affected:$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pmdrivers/net/ethernet/atheros/ag71xx.cdrivers/net/ethernet/microchip/sparx5/sparx5_main.cdrivers/net/ethernet/microchip/lan966x/lan966x_main.cdrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.cdrivers/net/ethernet/freescale/fs_enet/fs_enet-main.cdrivers/net/ethernet/freescale/dpaa/dpaa_eth.cdrivers/net/ethernet/freescale/ucc_geth.cdrivers/net/ethernet/freescale/enetc/enetc_pf_common.cdrivers/net/ethernet/marvell/mvpp2/mvpp2_main.cdrivers/net/ethernet/marvell/mvneta.cdrivers/net/ethernet/marvell/prestera/prestera_main.cdrivers/net/ethernet/mediatek/mtk_eth_soc.cdrivers/net/ethernet/altera/altera_tse_main.cdrivers/net/ethernet/wangxun/txgbe/txgbe_phy.cdrivers/net/ethernet/meta/fbnic/fbnic_phylink.cdrivers/net/ethernet/tehuti/tn40_phy.cdrivers/net/ethernet/mscc/ocelot_net.cMake the existing conditions dependent on the PHY device having aphydev->phy_link_change() implementation equal to the defaultphy_link_change() provided by phylib. Otherwise, we implicitly know thatthe phydev has the phylink-provided phylink_phy_change() callback, andwhen phylink is used, the PHY state machine always needs to be stopped/started on the suspend/resume path. The code is structured as such thatif phydev->phy_link_change() is absent, it is a matter of time until thekernel will crash - no need to further complicate the test.Thus, for the situation where the PM is not managed b---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interceptionPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested modeon vCPU reset") addressed an issue where a triple fault occurring innested mode could lead to use-after-free scenarios. However, the commitdid not handle the analogous situation for System Management Mode (SMM).This omission results in triggering a WARN when KVM forces a vCPU INITafter SHUTDOWN interception while the vCPU is in SMM. This situation wasreprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple faultThe issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improperemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs todo _something_ sane with the VMCB, since it's technically undefined, andINIT is the least awful choice given KVM's ABI.So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out ofSMM to avoid any weirdness (and the WARN).Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[sean: massage changelog, make it clear this isn't architectural behavior]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:mm/huge_memory: fix dereferencing invalid pmd migration entryWhen migrating a THP, concurrent access to the PMD migration entry duringa deferred split scan can lead to an invalid address access, asillustrated below. To prevent this invalid access, it is necessary tocheck the PMD migration entry and return early. In this context, there isno need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify theequality of the target folio. Since the PMD migration entry is locked, itcannot be served as the target.Mailing list discussion and explanation from Hugh Dickins: "An anon_vmalookup points to a location which may contain the folio of interest, butmight instead contain another folio: and weeding out those other folios isprecisely what the "folio != pmd_folio((*pmd)" check (and the "risk ofreplacing the wrong folio" comment a few lines above it) is for."BUG: unable to handle page fault for address: ffffea60001db008CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60Call Trace:try_to_migrate_one+0x28c/0x3730rmap_walk_anon+0x4f6/0x770unmap_folio+0x196/0x1f0split_huge_page_to_list_to_order+0x9f6/0x1560deferred_split_scan+0xac5/0x12a0shrinker_debugfs_scan_write+0x376/0x470full_proxy_write+0x15c/0x220vfs_write+0x2fc/0xcb0ksys_write+0x146/0x250do_syscall_64+0x6a/0x120entry_SYSCALL_64_after_hwframe+0x76/0x7eThe bug is found by syzkaller on an internal kernel, then confirmed onupstream.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Scrub packet on bpf_redirect_peerWhen bpf_redirect_peer is used to redirect packets to a device inanother network namespace, the skb isn't scrubbed. That can lead skbinformation from one namespace to be "misused" in another namespace.As one example, this is causing Cilium to drop traffic when usingbpf_redirect_peer to redirect packets that just went through IPsecdecryption to a container namespace. The following pwru trace shows (1)the packet path from the host's XFRM layer to the container's XFRMlayer where it's dropped and (2) the number of active skb extensions ateach function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2,In this case, there are no XFRM policies in the container's networknamespace so the drop is unexpected. When we decrypt the IPsec packet,the XFRM state used for decryption is set in the skb extensions. Thisinformation is preserved across the netns switch. When we reach theXFRM policy check in the container's netns, __xfrm_policy_check dropsthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRMpolicy can't be found that matches the (host-side) XFRM state used fordecryption.This patch fixes this by scrubbing the packet when usingbpf_redirect_peer, as is done on typical netns switches via vethdevices except skb->mark and skb->tstamp are not zeroed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix uninit-value for saddr in do_output_route4syzbot reports for uninit-value for the saddr argument [1].commit 4754957f04f5 ("ipvs: do not use random local source address fortunnels") already implies that the input value of saddrshould be ignored but the code is still reading it which can preventto connect the route. Fix it by changing the argument to ret_saddr.[1]BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)Hardware name: Google Google Compute Engi---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix deadlockThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlockfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connectormutex is only locked if a connection is established and the partner pointeris valid. This resolves a deadlock scenario whereucsi_displayport_remove_partner holds con->mutex waiting fordp_altmode_work to complete while dp_altmode_work attempts to acquire it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: opt3001: fix deadlock due to concurrent flag accessThe threaded IRQ function in this driver is reading the flag twice: once tolock a mutex and once to unlock it. Even though the code setting the flagis designed to prevent it, there are subtle cases where the flag could betrue at the mutex_lock stage and false at the mutex_unlock stage. Thisresults in the mutex not being unlocked, resulting in a deadlock.Fix it by making the opt3001_irq() code generally more robust, reading theflag into a variable and using the variable value at both stages.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifoPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop incase pattern_len is equal to zero and the device FIFO is not empty.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifoPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in casepattern_len is equal to zero and the device FIFO is not empty.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: fix memory leak in wl1251_tx_workThe skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup failswith a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:USB: wdm: close race between wdm_open and wdm_wwan_port_stopClearing WDM_WWAN_IN_USE must be the last action orwe can open a chardev whose URBs are still poisoned

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: leds: fix memory leakA network restart test on a router led to an out-of-memory condition,which was traced to a memory leak in the PHY LED trigger code.The root cause is misuse of the devm API. The registration function(phy_led_triggers_register) is called from phy_attach_direct, notphy_probe, and the unregister function (phy_led_triggers_unregister)is called from phy_detach, not phy_remove. This means the register andunregister functions can be called multiple times for the same PHYdevice, but devm-allocated memory is not freed until the driver isunbound.This also prevents kmemleak from detecting the leak, as the devm APIinternally stores the allocated pointer.Fix this by replacing devm_kzalloc/devm_kcalloc with standardkzalloc/kcalloc, and add the corresponding kfree calls in the unregisterpath.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()The function brcmf_usb_dl_writeimage() calls the functionbrcmf_usb_dl_cmd() but dose not check its return value. The'state.state' and the 'state.bytes' are uninitialized if thefunction brcmf_usb_dl_cmd() fails. It is dangerous to useuninitialized variables in the conditions.Add error handling for brcmf_usb_dl_cmd() to jump to errorhandling path if the brcmf_usb_dl_cmd() fails and the'state.state' and the 'state.bytes' are uninitialized.Improve the error message to report more detailed errorinformation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Flush gso_skb list too during ->change()Previously, when reducing a qdisc's limit via the ->change() operation, onlythe main skb queue was trimmed, potentially leaving packets in the gso_skblist. This could result in NULL pointer dereference when we only checksch->limit against sch->q.qlen.This patch introduces a new helper, qdisc_dequeue_internal(), which ensuresboth the gso_skb list and the main queue are properly flushed when trimmingexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)are updated to use this helper in their ->change() routines.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nfs: handle failure of nfs_get_lock_context in unlock pathWhen memory is insufficient, the allocation of nfs_lock_context innfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treatan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)as valid and proceed to execute rpc_run_task(), this will trigger a NULLpointer dereference in nfs4_locku_prepare. For example:BUG: kernel NULL pointer dereference, address: 000000000000000cPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40Workqueue: rpciod rpc_async_scheduleRIP: 0010:nfs4_locku_prepare+0x35/0xc2Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in:CR2: 000000000000000c---[ end trace 0000000000000000 ]---Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails andreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointerdereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bugCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fIn the function rxe_create_cq, when rxe_cq_from_init fails, the functionrxe_cleanup will be called to handle the allocated resources. In fact,some memory resources have already been freed in the functionrxe_cq_from_init. Thus, this problem will occur.The solution is to let rxe_cleanup do all the work.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free in cifs_fill_direntThere is a race condition in the readdir concurrency process, which mayaccess the rsp buffer after it has been released, triggering thefollowing KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================POC is available in the link [1].The problem triggering process is as follows:Process 1 Process 2--------------------------------------truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_doneSyzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_donemay still visit it in cryptd_queue_worker workqueue.I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1The key of reproduction is that, simd_aead_encrypt is interrupted, leadingto crypto_simd_usable() return false. Thus, the cryptd_queue_worker istriggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)Fix this by holding net reference count before encrypt.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix null-ptr-deref in idpf_features_checkidpf_features_check is used to validate the TX packet. skb headerlength is compared with the hardware supported value received fromthe device control plane. The value is stored in the adapter structureand to access it, vport pointer is used. During reset all the vportsare released and the vport pointer that the netdev private structurepoints to is NULL.To avoid null-ptr-deref, store the max header length value in netdevprivate structure. This also helps to cache the value and avoidaccessing adapter pointer in hot path.BUG: kernel NULL pointer dereference, address: 0000000000000068...RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: fix skb leaksA few error paths are missing a kfree_skb.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:libnvdimm/labels: Fix divide error in nd_label_data_init()If a faulty CXL memory device returns a broken zero LSA size in itsmemory device information (Identify Memory Device (Opcode 4000h), CXLspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimmdriver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]Code and flow:1) CXL Command 4000h returns LSA size = 02) config_size is assigned to zero LSA size (CXL pmem driver):drivers/cxl/pmem.c: .config_size = mds->lsa_size,3) max_xfer is set to zero (nvdimm driver):drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);4) A subsequent DIV_ROUND_UP() causes a division by zero:drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,drivers/nvdimm/label.c- config_size);Fix this by checking the config size parameter by extending anexisting check.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()If the 'buf' array received from the user contains an empty string, the'length' variable will be zero. Accessing the 'buf' array element withindex 'length - 1' will result in a buffer overflow.Add a check for an empty string.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix race of buffer access at PCM OSS layerThe PCM OSS layer tries to clear the buffer with the silence data atinitialization (or reconfiguration) of a stream with the explicit callof snd_pcm_format_set_silence() with runtime->dma_area. But this maylead to a UAF because the accessed runtime->dma_area might be freedconcurrently, as it's performed outside the PCM ops.For avoiding it, move the code into the PCM core and perform it insidethe buffer access lock, so that it won't be changed during theoperation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: cadence: macb: Fix a possible deadlock in macb_halt_tx.There is a situation where after THALT is set high, TGO stays high aswell. Because jiffies are never updated, as we are in a context withinterrupts disabled, we never exit that loop and have a deadlock.That deadlock was noticed on a sama5d4 device that stayed locked for days.Use retries instead of jiffies so that the timeout really works and we donot have a deadlock anymore.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: insert memory barrier before updating num_fencessmp_store_mb() inserts memory barrier after storing operation.It is different with what the comment is originally aiming so Nullpointer dereference can be happened if memory update is reordered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: don't warn when if there is a FW erroriwl_trans_reclaim is warning if it is called when the FW is not alive.But if it is called when there is a pending restart, i.e. after a FWerror, there is no need to warn, instead - return silently.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: fix a potential crash on gso_skb handlingSFQ has an assumption of always being able to queue at least one packet.However, after the blamed commit, sch->q.len can be inflated by packetsin sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followedby an immediate drop.Fix sfq_drop() to properly clear q->tail in this situation.ip netns add lbip link add dev to-lb type veth peer name in-lb netns lbethtool -K to-lb tso off # force qdisc to requeue gso_skbip netns exec lb ethtool -K in-lb gro on # enable NAPIip link set dev to-lb upip -netns lb link set dev in-lb upip addr add dev to-lb 192.168.20.1/24ip -netns lb addr add dev in-lb 192.168.20.2/24tc qdisc replace dev to-lb root sfq limit 100ip netns exec lb netservernetperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: ufs: Fix a hang in the error handlerufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latterfunction can only succeed if UFSHCD_EH_IN_PROGRESS is not set becauseresuming involves submitting a SCSI command and ufshcd_queuecommand()returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix thishang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() hasbeen called instead of before.Backtrace:__switch_to+0x174/0x338__schedule+0x600/0x9e4schedule+0x7c/0xe8schedule_timeout+0xa4/0x1c8io_schedule_timeout+0x48/0x70wait_for_common_io+0xa8/0x160 //waiting on START_STOPwait_for_completion_io_timeout+0x10/0x20blk_execute_rq+0xe4/0x1e4scsi_execute_cmd+0x108/0x244ufshcd_set_dev_pwr_mode+0xe8/0x250__ufshcd_wl_resume+0x94/0x354ufshcd_wl_runtime_resume+0x3c/0x174scsi_runtime_resume+0x64/0xa4rpm_resume+0x15c/0xa1c__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoingufshcd_err_handler+0x1a0/0xd08process_one_work+0x174/0x808worker_thread+0x15c/0x490kthread+0xf4/0x1ecret_from_fork+0x10/0x20[ bvanassche: rewrote patch description ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:gve: add missing NULL check for gve_alloc_pending_packet() in TX DQOgve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()did not check for this case before dereferencing the returned pointer.Add a missing NULL check to prevent a potential NULL pointerdereference when allocation fails.This improves robustness in low-memory scenarios.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Tx scheduler error handling in XDP callbackWhen the XDP program is loaded, the XDP callback adds new Tx queues.This means that the callback must update the Tx scheduler with the newqueue number. In the event of a Tx scheduler failure, the XDP callbackshould also fail and roll back any changes previously made for XDPpreparation.The previous implementation had a bug that not all changes made by theXDP callback were rolled back. This caused the crash with the followingcall trace:[ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5[ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI[ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)[ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022[ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice][...][ +0.002715] Call Trace:[ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29[ +0.003922] ? die_addr+0x3c/0x60[ +0.003319] ? exc_general_protection+0x17c/0x400[ +0.004707] ? asm_exc_general_protection+0x26/0x30[ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice][ +0.004835] ice_napi_poll+0x665/0x680 [ice][ +0.004320] __napi_poll+0x28/0x190[ +0.003500] net_rx_action+0x198/0x360[ +0.003752] ? update_rq_clock+0x39/0x220[ +0.004013] handle_softirqs+0xf1/0x340[ +0.003840] ? sched_clock_cpu+0xf/0x1f0[ +0.003925] __irq_exit_rcu+0xc2/0xe0[ +0.003665] common_interrupt+0x85/0xa0[ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40[ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690Fix this by performing the missing unmapping of XDP queues fromq_vectors and setting the XDP rings pointer back to NULL after all thosequeues are released.Also, add an immediate exit from the XDP callback in case of ringpreparation failure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: Add NULL check in udma_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,udma_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: pm8941: Add NULL check in wled_configure()devm_kasprintf() returns NULL when memory allocation fails. Currently,wled_configure() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()devm_kasprintf() returns NULL when memory allocation fails. Currently,aspeed_lpc_enable_snoop() does not check for this case, which results in aNULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.[arj: Fix Fixes: tag to use subject from 3772e5da4454]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Don't call calipso functions for AF_INET sk.syzkaller reported a null-ptr-deref in txopt_get(). [0]The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,so struct ipv6_pinfo was NULL there.However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6is always set in inet6_create(), meaning the socket was not IPv6 one.The root cause is missing validation in netlbl_conn_setattr().netlbl_conn_setattr() switches branches based on structsockaddr.sa_family, which is passed from userspace. However,netlbl_conn_setattr() does not check if the address family matchesthe socket.The syzkaller must have called connect() for an IPv6 address onan IPv4 socket.We have a proper validation in tcp_v[46]_connect(), butsecurity_socket_connect() is called in the earlier stage.Let's copy the validation to netlbl_conn_setattr().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]RIP: 0010:Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00cRDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9eR10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0PKRU: 80000000Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f901b61a12dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12dRDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,raspberrypi_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearerThe reproduction steps:1. create a tun interface2. enable l2 bearer3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tuntipc: Started in network modetipc: Node identity 8af312d38a21, cluster identity 4711tipc: Enabled bearer , priority 1Oops: general protection faultKASAN: null-ptr-deref in rangeCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPTHardware name: QEMU Ubuntu 24.04 PCRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0the ub was in fact a struct dev.when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL orother media when other thread changes it.fix this by checking media_id.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Free invalid length skb in atmtcp_c_send().syzbot reported the splat below. [0]vcc_sendmsg() copies data passed from userspace to skb and passesit to vcc->dev->ops->send().atmtcp_c_send() accesses skb->data as struct atmtcp_hdr afterchecking if skb->len is 0, but it's not enough.Also, when skb->len == 0, skb and sk (vcc) were leaked becausedev_kfree_skb() is not called and sk_wmem_alloc adjustment is missingto revert atm_account_tx() in vcc_sendmsg(), which is expectedto be done in atm_pop_raw().Let's properly free skb with an invalid length in atmtcp_c_send().[0]:BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Revert atm_account_tx() if copy_from_iter_full() fails.In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc byatm_account_tx().It is expected to be reverted by atm_pop_raw() later called byvcc->dev->ops->send(vcc, skb).However, vcc_sendmsg() misses the same revert when copy_from_iter_full()fails, and then we will leak a socket.Let's factorise the revert part as atm_return_tx() and call it inthe failure path.Note that the corresponding sk_wmem_alloc operation can be found inalloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Make sure modelist not set on unregistered consoleIt looks like attempting to write to the "store_modes" sysfs node willrun afoul of unregistered consoles:UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28index -1 is out of range for type 'fb_info *[32]'... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439static struct fb_info *fbcon_registered_fb[FB_MAX];...static signed char con2fb_map[MAX_NR_CONSOLES];...static struct fb_info *fbcon_info_from_console(int console)... return fbcon_registered_fb[con2fb_map[console]];If con2fb_map contains a -1 things go wrong here. Instead, return NULL,as callers of fbcon_info_from_console() are trying to compare againstexisting "info" pointers, so error handling should kick in correctly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAXOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()when resizing hashtable because __GFP_NOWARN is unset.Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: add NULL check in automount_fullpathpage is checked for null in __build_path_from_dentry_optional_prefixwhen tcon->origin_fullpath is not set. However, the check is missing whenit is set.Add a check to prevent a potential NULL pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in fb_set_var() fails to allocate memory forfb_videomode, later it may lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================The reason is that fb_info->var is being modified in fb_set_var(), andthen fb_videomode_to_var() is called. If it fails to add the mode tofb_info->modelist, fb_set_var() returns error, but does not restore theold value of fb_info->var. Restore fb_info->var on failure the same wayit is done earlier in the function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Cleanup after an allocation errorWhen allocation failures are not cleaned up by the driver, furtherallocation errors will be false-positives, which will cause buffers toremain uninitialized and cause NULL pointer dereferences.Ensure proper cleanup of failed allocations to prevent these issues.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: prevent NULL deref in clip_push()Blamed commit missed that vcc_destroy_socket() callsclip_push() with a NULL skb.If clip_devs is NULL, clip_push() then crashes when readingskb->truesize.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd9335: Fix missing free of regulator suppliesDriver gets and enables all regulator supplies in probe path(wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanupin final error paths and in unbind (missing remove() callback). Thisleads to leaked memory and unbalanced regulator enable count duringprobe errors or unbind.Fix this by converting entire code into devm_regulator_bulk_get_enable()which also greatly simplifies the code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix NULL pointer in cache_set_flush()1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc().2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set().3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 }(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885).(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL.LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().As (1), in LINE#1885 callbch_cache_set_unregister()---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 }(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below:[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory[ 846.713242] bcache: register_bcache() error : failed to register device[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8[ 846.714790] PGD 0 P4D 0[ 846.715129] Oops: 0000 [#1] SMP PTI[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018[ 846.716451] Workqueue: events cache_set_flush [bcache][ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache][ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: b53: do not enable EEE on bcm63xxBCM63xx internal switches do not support EEE, but provide multiple RGMIIports where external PHYs may be connected. If one of these PHYs are EEEcapable, we may try to enable EEE for the MACs, which then hangs thesystem on access of the (non-existent) EEE registers.Fix this by checking if the switch actually supports EEE beforeattempting to configure it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid __bpf_prog_ret0_warn when jit failssyzkaller reported an issue:WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Modules linked in:CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ...When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not setand bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,but jit failed due to FAULT_INJECTION. As a result, incorrectlytreats the program as valid, when the program runs it calls`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix WARN() in get_bpf_raw_tp_regssyzkaller reported an issue:WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861Modules linked in:CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4cRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47Tracepoint like trace_mmap_lock_acquire_returned may cause nested callas the corner case show above, which will be resolved with more generalmethod in the future. As a result, WARN_ON_ONCE will be triggered. AsAlexei suggested, remove the WARN_ON_ONCE first.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()There is no disagreement that we should check both ptp->is_virtual_clockand ptp->n_vclocks to check if the ptp virtual clock is in use.However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks inptp_vclock_in_use(), we observe a recursive lock in the call tracestarting from n_vclocks_store().============================================WARNING: possible recursive locking detected6.15.0-rc6 #1 Not tainted--------------------------------------------syz.0.1540/13807 is trying to acquire lock:ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415but task is already holding lock:ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK ***....============================================The best way to solve this is to remove the logic that checksptp->n_vclocks in ptp_vclock_in_use().The reason why this is appropriate is that any path that usesptp->n_vclocks must unconditionally check if ptp->n_vclocks is greaterthan 0 before unregistering vclocks, and all functions are alreadywritten this way. And in the function that uses ptp->n_vclocks, wealready get ptp->n_vclocks_mux before unregistering vclocks.Therefore, we need to remove the redundant check for ptp->n_vclocks inptp_vclock_in_use() to prevent recursive locking.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix double-free on mc_devThe blamed commit tried to simplify how the deallocations are done but,in the process, introduced a double-free on the mc_dev variable.In case the MC device is a DPRC, a new mc_bus is allocated and themc_dev variable is just a reference to one of its fields. In thiscircumstance, on the error path only the mc_bus should be freed.This commit introduces back the following checkpatch warning which is afalse-positive.WARNING: kfree(NULL) is safe and this check is probably not required+ if (mc_bus)+ kfree(mc_bus);

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_tableThe function atomctrl_initialize_mc_reg_table() andatomctrl_initialize_mc_reg_table_v2_2() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()fails to retrieve vram_info, it returns NULL which is laterdereferenced.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:aoe: clean device rq_list in aoedev_downdev()An aoe device's rq_list contains accepted block requests that arewaiting to be transmitted to the aoe target. This queue was added aspart of the conversion to blk_mq. However, the queue was not cleaned outwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleepindefinitely waiting for those requests to complete, causing a hang. Thisfix cleans out the queue before calling blk_mq_freeze_queue().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Use memcpy() for BIOS versionThe strlcat() with FORTIFY support is triggering a panic because itthinks the target buffer will overflow although the correct targetbuffer size is passed in.Anyway, instead of memset() with 0 followed by a strlcat(), just usememcpy() and ensure that the resulting buffer is NULL terminated.BIOSVersion is only used for the lpfc_printf_log() which expects aproperly terminated string.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()Since handle->h_transaction may be a NULL pointer, so we should change itto call is_handle_aborted(handle) first before dereferencing it.And the following data-race was reported in my fuzzer:==================================================================BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadatawrite to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....value changed: 0x00000000 -> 0x00000001==================================================================This issue is caused by missing data-race annotation for jh->b_modified.Therefore, the missing annotation needs to be added.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi parse and parseext cache leaksACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5I'm Seunghun Han, and I work for National Security Research Institute ofSouth Korea.I have been doing a research on ACPI and found an ACPI cache leak in ACPIearly abort cases.Boot log of ACPI cache leak is as follows:[ 0.352414] ACPI: Added _OSI(Module Device)[ 0.353182] ACPI: Added _OSI(Processor Device)[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)[ 0.356028] ACPI: Unable to start the ACPI Interpreter[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #10[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.361873] Call Trace:[ 0.362243] ? dump_stack+0x5c/0x81[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27[ 0.363296] ? acpi_os_delete_cache+0xa/0x10[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.364000] ? acpi_terminate+0xa/0x14[ 0.364000] ? acpi_init+0x2af/0x34f[ 0.364000] ? __class_create+0x4c/0x80[ 0.364000] ? video_setup+0x7f/0x7f[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27[ 0.364000] ? do_one_initcall+0x4e/0x1a0[ 0.364000] ? kernel_init_freeable+0x189/0x20a[ 0.364000] ? rest_init+0xc0/0xc0[ 0.364000] ? kernel_init+0xa/0x100[ 0.364000] ? ret_from_fork+0x25/0x30I analyzed this memory leak in detail. I found that "Acpi-State" cache and"Acpi-Parse" cache were merged because the size of cache objects was sameslab cache size.I finally found "Acpi-Parse" cache and "Acpi-parse_ext" cache were leakedusing SLAB_NEVER_MERGE flag in kmem_cache_create() function.Real ACPI cache leak point is as follows:[ 0.360101] ACPI: Added _OSI(Module Device)[ 0.360101] ACPI: Added _OSI(Processor Device)[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)[ 0.364016] ACPI: Unable to start the ACPI Interpreter[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.372000] Call Trace:[ 0.372000] ? dump_stack+0x5c/0x81[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? acpi_os_delete_cache+0xa/0x10[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b[ 0.372000] ? acpi_terminate+0xa/0x14[ 0.372000] ? acpi_init+0x2af/0x34f[ 0.372000] ? __class_create+0x4c/0x80[ 0.372000] ? video_setup+0x7f/0x7f[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? do_one_initcall+0x4e/0x1a0[ 0.372000] ? kernel_init_freeable+0x189/0x20a[ 0.372000] ? rest_init+0xc0/0xc0[ 0.372000] ? kernel_init+0xa/0x100[ 0.372000] ? ret_from_fork+0x25/0x30[ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.392000] Call Trace:[ 0.392000] ? dump_stack+0x5c/0x81[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27[ 0.392000] ? acpi_os_delete_cache+0xa/0x10[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.392000] ? acpi_terminate+0xa/0x14[ 0.392000] ? acpi_init+0x2af/0x3---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Fix in_atomic() handling in do_secure_storage_access()Kernel user spaces accesses to not exported pages in atomic contextincorrectly try to resolve the page fault.With debug options enabled call traces like this can be seen:BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39preempt_count: 1, expected: 0RCU nest depth: 0, expected: 0INFO: lockdep is turned off.Preemption disabled at:[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPTTainted: [W]=WARNHardware name: IBM 3931 A01 703 (LPAR)Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90INFO: lockdep is turned off.It is not allowed to take the mmap_lock while in atomic context. Thereforehandle such a secure storage access fault as if the accessed page is notmapped: the uaccess function will return -EFAULT, and the caller has todeal with this. Usually this means that the access is retried in processcontext, which allows to resolve the page fault (or in this case export thepage).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check for get_first_active_display()The function mod_hdcp_hdcp1_enable_encryption() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference inmod_hdcp_hdcp2_enable_encryption().Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix a possible null pointer dereferenceIn tegra_crtc_reset(), new memory is allocated with kzalloc(), butno check is performed. Before calling __drm_atomic_helper_crtc_reset,state should be checked to prevent possible null pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before usingRunning IDXD workloads in a container with the /dev directory mounted cantrigger a call trace or even a kernel panic when the parent process of thecontainer is terminated.This issue occurs because, under certain configurations, Docker does notproperly propagate the mount replica back to the original mount point.In this case, when the user driver detaches, the WQ is destroyed but itstill calls destroy_workqueue() attempting to completes all pending work.It's necessary to check wq->wq and skip the drain if it no longer exists.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Disable interrupts before resetting the GPUCurrently, an interrupt can be triggered during a GPU reset, which canlead to GPU hangs and NULL pointer dereference in an interrupt contextas shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---Before resetting the G---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Refuse to evaluate a method if arguments are missingAs reported in [1], a platform firmware update that increased the numberof method parameters and forgot to update a least one of its callers,caused ACPICA to crash due to use-after-free.Since this a result of a clear AML issue that arguably cannot be fixedup by the interpreter (it cannot produce missing data out of thin air),address it by making ACPICA refuse to evaluate a method if the callerattempts to pass fewer arguments than expected to it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix timeline left held on VMA alloc errorThe following error has been reported sporadically by CI when a testunbinds the i915 driver on a ring submission platform:<4> [239.330153] ------------[ cut here ]------------<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330942] Call Trace:<4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915]<4> [239.331202] i915_driver_release+0x86/0xa0 [i915]<4> [239.331482] devm_drm_dev_init_release+0x61/0x90<4> [239.331494] devm_action_release+0x15/0x30<4> [239.331504] release_nodes+0x3d/0x120<4> [239.331517] devres_release_all+0x96/0xd0<4> [239.331533] device_unbind_cleanup+0x12/0x80<4> [239.331543] device_release_driver_internal+0x23a/0x280<4> [239.331550] ? bus_find_device+0xa5/0xe0<4> [239.331563] device_driver_detach+0x14/0x20...<4> [357.719679] ---[ end trace 0000000000000000 ]---If the test also unloads the i915 module then that's followed with:<3> [357.787478] =============================================================================<3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown()<3> [357.788031] -----------------------------------------------------------------------------<3> [357.788204] Object 0xffff888109e7f480 @offset=29824<3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244<4> [357.788994] i915_vma_instance+0xee/0xc10 [i915]<4> [357.789290] init_status_page+0x7b/0x420 [i915]<4> [357.789532] intel_engines_init+0x1d8/0x980 [i915]<4> [357.789772] intel_gt_init+0x175/0x450 [i915]<4> [357.790014] i915_gem_init+0x113/0x340 [i915]<4> [357.790281] i915_driver_probe+0x847/0xed0 [i915]<4> [357.790504] i915_pci_probe+0xe6/0x220 [i915]...Closer analysis of CI results history has revealed a dependency of theerror on a few IGT tests, namely:- igt@api_intel_allocator@fork-simple-stress-signal,- igt@api_intel_allocator@two-level-inception-interruptible,- igt@gem_linear_blits@interruptible,- igt@prime_mmap_coherency@ioctl-errors,which invisibly trigger the issue, then exhibited with first driver unbindattempt.All of the above tests perform actions which are actively interrupted withsignals. Further debugging has allowed to narrow that scope down toDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ringsubmission, in particular.If successful then that function, or its execlists or GuC submissionequivalent, is supposed to be called only once per GEM context engine,followed by raise of a flag that prevents the function from being calledagain. The function is expected to unwind its internal errors itself, soit may be safely called once more after it returns an error.In case of ring submission, the function first gets a reference to theengine's legacy timeline and then allocates a VMA. If the VMA allocationfails, e.g. when i915_vma_instance() called from inside is interruptedwith a signal, then ring_context_alloc() fails, leaving the timeline heldreferenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to thetimeline is got, and only that last one is put on successful completion.As a consequence, the legacy timeline, with its underlying engine statuspage's VMA object, is still held and not released on driver unbind.Get the legacy timeline only after successful allocation of the contextengine's VMA.v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert control queue mutex to a spinlockWith VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generatedon module load:[ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578[ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager[ 324.701689] preempt_count: 201, expected: 0[ 324.701693] RCU nest depth: 0, expected: 0[ 324.701697] 2 locks held by NetworkManager/1582:[ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0[ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870[ 324.701749] Preemption disabled at:[ 324.701752] [] __dev_open+0x3dd/0x870[ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)[ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022[ 324.701774] Call Trace:[ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80[ 324.701788] ? __dev_open+0x3dd/0x870[ 324.701793] __might_resched.cold+0x1ef/0x23d<..>[ 324.701818] __mutex_lock+0x113/0x1b80<..>[ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf][ 324.701935] ? kasan_save_track+0x14/0x30[ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]<..>[ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf][ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf][ 324.702021] ? rcu_is_watching+0x12/0xc0[ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]<..>[ 324.702122] __hw_addr_sync_dev+0x1cf/0x300[ 324.702126] ? find_held_lock+0x32/0x90[ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf][ 324.702152] __dev_open+0x3f8/0x870[ 324.702159] ? __pfx___dev_open+0x10/0x10[ 324.702174] __dev_change_flags+0x443/0x650<..>[ 324.702208] netif_change_flags+0x80/0x160[ 324.702218] do_setlink.isra.0+0x16a0/0x3960<..>[ 324.702349] rtnl_newlink+0x12fd/0x21e0The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock)Fix by converting cq_lock to a spinlock. All operations under the newlock are safe except freeing the DMA memory, which may use vunmap(). Fixby requesting a contiguous physical memory for the DMA mapping.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()The function core_scsi3_decode_spec_i_port(), in its error code path,unconditionally calls core_scsi3_lunacl_undepend_item() passing thedest_se_deve pointer, which may be NULL.This can lead to a NULL pointer dereference if dest_se_deve remainsunset.SPC-3 PR SPEC_I_PT: Unable to locate dest_tpgUnable to handle kernel paging request at virtual address dfff800000000012Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]Fix this by adding a NULL check before callingcore_scsi3_lunacl_undepend_item()

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: return 0 size for RSS key if not supportedReturning -EOPNOTSUPP from function returning u32 is leading tocast and invalid size value as a result.-EOPNOTSUPP as a size probably will lead to allocation fail.Command: ethtool -x eth0It is visible on all devices that don't have RSS caps set.[ 136.615917] Call Trace:[ 136.615921] [ 136.615927] ? __warn+0x89/0x130[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.615953] ? report_bug+0x164/0x190[ 136.615968] ? handle_bug+0x58/0x90[ 136.615979] ? exc_invalid_op+0x17/0x70[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.616028] __alloc_pages_noprof+0xe/0x20[ 136.616038] ___kmalloc_large_node+0x80/0x110[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0[ 136.616081] __kmalloc_noprof+0x32c/0x4c0[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170[ 136.616114] ethnl_default_doit+0x107/0x3d0[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160[ 136.616147] genl_rcv_msg+0x1b8/0x2c0[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10[ 136.616176] netlink_rcv_skb+0x58/0x110[ 136.616186] genl_rcv+0x28/0x40[ 136.616195] netlink_unicast+0x19b/0x290[ 136.616206] netlink_sendmsg+0x222/0x490[ 136.616215] __sys_sendto+0x1fd/0x210[ 136.616233] __x64_sys_sendto+0x24/0x30[ 136.616242] do_syscall_64+0x82/0x160[ 136.616252] ? __sys_recvmsg+0x83/0xe0[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210[ 136.616275] ? do_syscall_64+0x8e/0x160[ 136.616282] ? __count_memcg_events+0xa1/0x130[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30[ 136.616306] ? handle_mm_fault+0xae/0x2d0[ 136.616319] ? do_user_addr_fault+0x379/0x670[ 136.616328] ? clear_bhb_loop+0x45/0xa0[ 136.616340] ? clear_bhb_loop+0x45/0xa0[ 136.616349] ? clear_bhb_loop+0x45/0xa0[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 136.616369] RIP: 0033:0x7fd30ba7b047[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix a fence leak in submit error pathIn error paths, we could unref the submit without callingdrm_sched_entity_push_job(), so msm_job_free() will never getcalled. Since drm_sched_job_cleanup() will NULL out thes_fence, we can use that to detect this case.Patchwork: https://patchwork.freedesktop.org/patch/653584/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacksAfter retrieving WMI data blocks in sysfs callbacks, check for thevalidity of them before dereferencing their content.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Release rproc->clean_table after rproc_attach() failsWhen rproc->state = RPROC_DETACHED is attached to remote processorthrough rproc_attach(), if rproc_handle_resources() returns failure,then the clean table should be released, otherwise the followingmemory leak will occur.unreferenced object 0xffff000086a99800 (size 1024):comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)hex dump (first 32 bytes):00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()When rproc->state = RPROC_DETACHED and rproc_attach() is usedto attach to the remote processor, if rproc_handle_resources()returns a failure, the resources allocated by imx_rproc_prepare()should be released, otherwise the following memory leak will occur.Since almost the same thing is done in imx_rproc_prepare() andrproc_resource_cleanup(), Function rproc_resource_cleanup() is ableto deal with empty lists so it is better to fix the "goto" statementsin rproc_attach(). replace the "unprepare_device" goto statement with"clean_up_resources" and get rid of the "unprepare_device" label.unreferenced object 0xffff0000861c5d00 (size 128):comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: do not ping device which has failed to load firmwareSyzkaller reports [1, 2] crashes caused by an attempts to pingthe device which has failed to load firmware. Since such a devicedoesn't pass 'ieee80211_register_hw()', an internal workqueuemanaged by 'ieee80211_queue_work()' is not yet created and anattempt to queue work on it causes null-ptr-deref.[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix sample vs do_exit()Baisheng Gao reported an ARM64 crash, which Mark decoded as being asynchronous external abort -- most likely due to trying to accessMMIO in bad ways.The crash further shows perf trying to do a user stack sample while inexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the addressspace it is trying to access.It turns out that we stop perf after we tear down the userspace mm; areceipie for disaster, since perf likes to access userspace forvarious reasons.Flip this order by moving up where we stop perf in do_exit().Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USERto abort when the current task does not have an mm (exit_mm() makessure to set current->mm = NULL; before commencing with the actualteardown). Such that CPU wide events don't trip on this same problem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Add basic validation for RAS headerIf RAS header read from EEPROM is corrupted, it could result in tryingto allocate huge memory for reading the records. Add some validation toheader fields.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: nfsd4_spo_must_allow() must check this is a v4 compound requestIf the request being processed is not a v4 compound request, thenexamining the cstate can have undefined results.This patch adds a check that the rpc procedure being executed(rq_procinfo) is the NFSPROC4_COMPOUND procedure.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.sof_pdata->tplg_filename can have address allocated by kstrdup()and can be overwritten. Memory leak was detected with kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:raid10: cleanup memleak at raid10_make_requestIf raid10_read_request or raid10_write_request registers a newrequest and the REQ_NOWAIT flag is set, the code does notfree the malloc from the mempool.unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7eV4: changing backing tree to see if CKI tests will pass.The patch code has not changed between any versions.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: Fix stack memory use after return in raid1_reshapeIn the raid1_reshape function, newpool isallocated on the stack and assigned to conf->r1bio_pool.This results in conf->r1bio_pool.wait.head pointingto a stack address.Accessing this address later can lead to a kernel panic.Example access path:raid1_reshape(){ // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool;}raid1_read_request() or raid1_write_request(){ alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } }}mempool_free(){ if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); }}Fix:reinit conf->r1bio_pool.wait after assigning newpool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Abort __tc_modify_qdisc if parent class does not existLion's patch [1] revealed an ancient bug in the qdisc API.Whenever a user creates/modifies a qdisc specifying as a parent anotherqdisc, the qdisc API will, during grafting, detect that the user isnot trying to attach to a class and reject. However grafting isperformed after qdisc_create (and thus the qdiscs' init callback) isexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlogduring init or change (such as fq, hhf, choke, etc), an issuearises. For example, executing the following commands:sudo tc qdisc add dev lo root handle a: htb default 2sudo tc qdisc add dev lo parent a: handle beef fqQdiscs such as fq, hhf, choke, etc unconditionally invokeqdisc_tree_reduce_backlog() in their control path init() or change() whichthen causes a failure to find the child class; however, that does not stopthe unconditional invocation of the assumed child qdisc's qlen_notify witha null class. All these qdiscs make the assumption that class is non-null.The solution is ensure that qdisc_leaf() which looks up the parentclass, and is invoked prior to qdisc_create(), should return failure onnot finding the class.In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever theparentid doesn't correspond to a class, so that we can detect itearlier on and abort before qdisc_create is called.[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix wraparounds of sk->sk_rmem_alloc.Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc);, which has the same problem fixed by commit 5a465a0da13e ("udp:Fix multiple wraparounds of sk->sk_rmem_alloc.").For example, if we set INT_MAX to SO_RCVBUFFORCE, the conditionis always false as the two operands are of int.Then, a single socket can eat as many skb as possible until OOMhappens, and we can see multiple wraparounds of sk->sk_rmem_alloc.Let's fix it by using atomic_add_return() and comparing the twovariables as unsigned int.Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 *After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtreehtb_lookup_leaf has a BUG_ON that can trigger with the following:tc 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 2: netemtc qdisc add dev lo parent 2:1 handle 3: blackholeping -I lo -c1 -W0.001 127.0.0.1The root cause is the following:1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc2. netem_dequeue calls enqueue on the child qdisc3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ONThe function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------The full original bug report can be seen here [1].We can fix this just by returning NULL instead of the BUG_ON,as htb_dequeue_tree returns NULL when htb_lookup_leaf returnsNULL.[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: net: sierra: check for no status endpointThe driver checks for having three endpoints andhaving bulk in and out endpoints, but not thatthe third endpoint is interrupt input.Rectify the omission.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: lpc-snoop: Don't disable channels that aren't enabledMitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion when building free space treeWhen building the free space tree with the block group tree featureenabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---This happens because we are processing an empty block group, which hasno extents allocated from it, there are no items for this block group,including the block group item since block group items are stored in adedicated tree when using the block group tree feature. It also meansthis is the block group with the highest start offset, so there are nohigher keys in the extent root, hence btrfs_search_slot_for_read()returns 1 (no higher key found).Fix this by asserting 'ret' is 0 only if the block group tree featureis not enabled, in which case we should find a block group item forthe block group since it's stored in the extent root and block groupitem keys are greater than extent item keys (the value forBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY andBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).In case 'ret' is 1, we just need to add a record to the free spacetree which spans the whole block group, and we can achieve this bymaking 'ret == 0' as the while loop's condition.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix oops due to non-existence of prealloc backlog structIf an AF_RXRPC service socket is opened and bound, but calls arepreallocated, then rxrpc_alloc_incoming_call() will oops because therxrpc_backlog struct doesn't get allocated until the first preallocation ismade.Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is nobacklog struct. This will cause the incoming call to be aborted.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: qcom: msm: mark certain pins as invalid for interruptsOn some platforms, the UFS-reset pin has no interrupt logic in TLMM butis nevertheless registered as a GPIO in the kernel. This enables theuser-space to trigger a BUG() in the pinctrl-msm driver by running, forexample: `gpiomon -c 0 113` on RB2.The exact culprit is requesting pins whose intr_detection_width settingis not 1 or 2 for interrupts. This hits a BUG() inmsm_gpio_irq_set_type(). Potentially crashing the kernel due to aninvalid request from user-space is not optimal, so let's go through thepins and mark those that would fail the check as invalid for the irq chipas we should not even register them as available irqs.This function can be extended if we determine that there are morecorner-cases like this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recv-recv race of completed callIf a call receives an event (such as incoming data), the call gets placedon the socket's queue and a thread in recvmsg can be awakened to go andprocess it. Once the thread has picked up the call off of the queue,further events will cause it to be requeued, and once the socket lock isdropped (recvmsg uses call->user_mutex to allow the socket to be used inparallel), a second thread can come in and its recvmsg can pop the call offthe socket queue again.In such a case, the first thread will be receiving stuff from the call andthe second thread will be blocked on call->user_mutex. The first threadcan, at this point, process both the event that it picked call for and theevent that the second thread picked the call for and may see the callterminate - in which case the call will be "released", decoupling the callfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the controlmessage).The first thread will return okay, but then the second thread will wake upholding the user_mutex and, if it sees that the call has been released bythe first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474!Fix this by just dequeuing the call and ignoring it if it is seen to bealready released. We can't tell userspace about it anyway as the user callID has become stale.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY modeWhen transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the codeassumed that the regulator should be disabled. However, if the regulatoris marked as always-on, regulator_is_enabled() continues to return true,leading to an incorrect attempt to disable a regulator which is notenabled.This can result in warnings such as:[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004_regulator_disable+0xe4/0x1a0[ 250.155652] unbalanced disables for VIN_SYS_5V0To fix this, we move the regulator control logic intotegra186_xusb_padctl_id_override() function since it's directly relatedto the ID override state. The regulator is now only disabled when the roletransitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_IDregister. This ensures that regulator enable/disable operations areproperly balanced and only occur when actually transitioning to/from hostmode.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP CamerasThe Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)report a HID sensor interface that is not actually implemented.Attempting to access this non-functional sensor via iio_info causessystem hangs as runtime PM tries to wake up an unresponsive sensor.Add these 2 devices to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (corsair-cpro) Validate the size of the received input bufferAdd buffer_recv_size to store the size of the received bytes.Validate buffer_recv_size in send_usb_cmd().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Delay put pmc->idev in mld_del_delrec()pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()does, the reference should be put after ip6_mc_clear_src() return.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Restrict conditions for adding duplicating netems to qdisc treenetem_enqueue's duplication prevention logic breaks when a netemresides in a qdisc tree with other netems - this can lead to asoft lockup and OOM loop in netem_dequeue, as seen in [1].Ensure that a duplicating netem cannot exist in a tree with othernetems.Previous approaches suggested in discussions in chronological order:1) Track duplication status or ttl in the sk_buff struct. Consideredtoo specific a use case to extend such a struct, though this wouldbe a resilient fix and address other previous and potential futureDOS bugs like the one described in loopy fun [2].2) Restrict netem_enqueue recursion depth like in act_mirred with aper cpu variable. However, netem_dequeue can call enqueue on itschild, and the depth restriction could be bypassed if the child is anetem.3) Use the same approach as in 2, but add metadata in netem_skb_cbto handle the netem_dequeue case and track a packet's involvementin duplication. This is an overly complex approach, and Jamalnotes that the skb cb can be overwritten to circumvent thissafeguard.4) Prevent the addition of a netem to a qdisc tree if its ancestralpath contains a netem. However, filters and actions can cause apacket to change paths when re-enqueued to the root from netemduplication, leading us to the current solution: prevent aduplicating netem from inhabiting the same tree as other netems.[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/[2] https://lwn.net/Articles/719297/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix crash when rebind ccp device for ccp.koWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebindingthe ccp device causes the following crash:$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 204.978026] #PF: supervisor write access in kernel mode[ 204.979126] #PF: error_code(0x0002) - not-present page[ 204.980226] PGD 0 P4D 0[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI...[ 204.997852] Call Trace:[ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0[ 205.001533] debugfs_create_dir+0x1f/0x170[ 205.002769] ? srso_return_thunk+0x5/0x5f[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp][ 205.005241] ccp5_init+0x8b2/0x960 [ccp][ 205.006469] ccp_dev_init+0xd4/0x150 [ccp][ 205.007709] sp_init+0x5f/0x80 [ccp][ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp][ 205.010165] ? srso_return_thunk+0x5/0x5f[ 205.011376] local_pci_probe+0x4f/0xb0[ 205.012584] pci_device_probe+0xdb/0x230[ 205.013810] really_probe+0xed/0x380[ 205.015024] __driver_probe_device+0x7e/0x160[ 205.016240] device_driver_attach+0x2f/0x60[ 205.017457] bind_store+0x7c/0xb0[ 205.018663] drv_attr_store+0x28/0x40[ 205.019868] sysfs_kf_write+0x5f/0x70[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0[ 205.022267] vfs_write+0x308/0x440[ 205.023453] ksys_write+0x6d/0xe0[ 205.024616] __x64_sys_write+0x1e/0x30[ 205.025778] x64_sys_call+0x16ba/0x2150[ 205.026942] do_syscall_64+0x56/0x1e0[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 205.029276] RIP: 0033:0x7fbc36f10104[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5This patch sets ccp_debugfs_dir to NULL after destroying it inccp5_debugfs_destroy, allowing the directory dentry to berecreated when rebinding the ccp device.Tested on AMD Ryzen 7 1700X.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:clk: xilinx: vcu: unregister pll_post only if registered correctlyIf registration of pll_post is failed, it will be set to NULL or ERR,unregistering same will fail with following call trace:Unable to handle kernel NULL pointer dereference at virtual address 008pc : clk_hw_unregister+0xc/0x20lr : clk_hw_unregister_fixed_factor+0x18/0x30sp : ffff800011923850...Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Remove skb secpath if xfrm state is not foundHardware returns a unique identifier for a decrypted packet's xfrmstate, this state is looked up in an xarray. However, the state mighthave been freed by the time of this lookup.Currently, if the state is not found, only a counter is incremented.The secpath (sp) extension on the skb is not removed, resulting insp->len becoming 0.Subsequently, functions like __xfrm_policy_check() attempt to accessfields such as xfrm_input_state(skb)->xso.type (which dereferencessp->xvec[sp->len - 1]) without first validating sp->len. This leads toa crash when dereferencing an invalid state pointer.This patch prevents the crash by explicitly removing the secpathextension from the skb if the xfrm state is not found after hardwaredecryption. This ensures downstream functions do not operate on azero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: clear initialized flag for deinit-ed srng listsIn a number of cases we see kernel panics on resume dueto ath11k kernel page fault, which happens under thefollowing circumstances:1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170Clear per-list ->initialized flag in ath11k_hal_srng_deinit().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iwlwifi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue since it mayreturn NULL pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Check governor before using governor->nameCommit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name fromstruct devfreq") removes governor_name and uses governor->name to replaceit. But devfreq->governor may be NULL and directly usingdevfreq->governor->name may cause null pointer exception. Move the check ofgovernor to before using governor->name.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()In the error paths after fb_info structure is successfully allocated,the memory allocated in fb_deferred_io_init() for info->pagerefs is notfreed. Fix that by adding the cleanup function on the error path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: drop UFO packets in udp_rcv_segment()When sending a packet with virtio_net_hdr to tun device, if the gso_typein virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdrsize, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set optionUDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcvhook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will tryto pull udphdr, but the skb size has been segmented to gso size, whichleads to this crash.Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")introduces segmentation in UDP receive path only for GRO, which was neverintended to be used for UFO, so drop UFO packets in udp_rcv_segment().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Clean up allocated IRQs on unplugWhen the root of a nested PCIe bridge configuration is unplugged, thepnv_php driver leaked the allocated IRQ resources for the child bridges'hotplug event notifications, resulting in a panic.Fix this by walking all child buses and deallocating all its IRQ resourcesbefore calling pci_hp_remove_devices().Also modify the lifetime of the workqueue at struct pnv_php_slot::wq sothat it is only destroyed in pnv_php_free_slot(), instead ofpnv_php_disable_irq(). This is required since pnv_php_disable_irq() willnow be called by workers triggered by hot unplug interrupts, so theworkqueue needs to stay allocated.The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec[bhelgaas: tidy comments]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cpcap-charger: Fix null check for power_supply_get_by_nameIn the cpcap_usb_detect() function, the power_supply_get_by_name()function may return `NULL` instead of an error pointer.To prevent potential null pointer dereferences, Added a null check.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()Callers of wdev_chandef() must hold the wiphy mutex.But the worker cfg80211_propagate_cac_done_wk() never takes the lock.Which triggers the warning below with the mesh_peer_connected_dfstest from hostapd and not (yet) released mac80211 code changes:WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165Modules linked in:CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cfWorkqueue: cfg80211 cfg80211_propagate_cac_done_wkStack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64irq event stamp: 614611hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xafhardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xafsoftirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Check device memory pointer before usageAdd a NULL check before accessing device memory to prevent a crash ifdev->dm allocation in mlx5_init_once() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_modeAndrei Lalaev reported a NULL pointer deref when a CAN device isrestarted from Bus Off and the driver does not implement the structcan_priv::do_set_mode callback.There are 2 code path that call struct can_priv::do_set_mode:- directly by a manual restart from the user space, via can_changelink()- delayed automatic restart after bus off (deactivated by default)To prevent the NULL pointer deference, refuse a manual restart orconfigure the automatic restart delay in can_changelink() and reportthe error via extack to user space.As an additional safety measure let can_restart() return an error ifcan_priv::do_set_mode is not set instead of dereferencing itunchecked.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix NULL dereference on unbind due to stale coupling dataFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs canlead to NULL pointer dereference when regulators are accessed post-unbind.This can happen during runtime PM or other regulator operations that relyon coupling metadata.For example, on ridesx4, unbinding the 'reg-dummy' platform device triggersa panic in regulator_lock_recursive() due to stale coupling state.Ensure n_coupled is set to 0 to prevent access to invalid pointers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to changeto different stacks along with the Shadow Call Stack if it is enabled.Those two stack changes cannot be done atomically and both functionscan be interrupted by SErrors or Debug Exceptions which, though unlikely,is very much broken : if interrupted, we can end up with mismatched stacksand Shadow Call Stack leading to clobbered stacks.In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,but x18 stills points to the old task's SCS. When the interrupt handlertries to save the task's SCS pointer, it will save the old taskSCS pointer (x18) into the new task struct (pointed to by SP_EL0),clobbering it.In `call_on_irq_stack()`, it can happen when switching from the task stackto the IRQ stack and when switching back. In both cases, we can beinterrupted when the SCS pointer points to the IRQ SCS, but SP points tothe task stack. The nested interrupt handler pushes its return addresseson the IRQ SCS. It then detects that SP points to the task stack,calls `call_on_irq_stack()` and clobbers the task SCS pointer withthe IRQ SCS pointer, which it will also use !This leads to tasks returning to addresses on the wrong SCS,or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACKor FPAC if enabled.This is possible on a default config, but unlikely.However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked andinstead the GIC is responsible for filtering what interrupts the CPUshould receive based on priority.Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPUeven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*frequently depending on the system configuration and workload, leadingto unpredictable kernel panics.Completely mask DAIF in `cpu_switch_to()` and restore it when returning.Do the same in `call_on_irq_stack()`, but restore and mask aroundthe branch.Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistencyof behaviour between all configurations.Introduce and use an assembly macro for saving and masking DAIF,as the existing one saves but only masks IF.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: qup: jump out of the loop in case of timeoutOriginal logic only sets the return value but doesn't jump out of theloop if the bus is kept active by a client. This is not expected. Amalicious or buggy i2c client can hang the kernel in this case andshould be avoided. This is observed during a long time test with aPCA953x GPIO extender.Fix it by changing the logic to not only sets the return value, but alsojumps out of the loop and return to the caller with -ETIMEDOUT.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:clk: samsung: Fix UBSAN panic in samsung_clk_init()With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due todereferencing `ctx->clk_data.hws` before setting`ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: use is_copy_from_user() to determine copy-from-user contextPatch series "mm/hwpoison: Fix regressions in memory failure handling",v4.## 1. What am I trying to do:This patchset resolves two critical regressions related to memory failurehandling that have appeared in the upstream kernel since version 5.17, ascompared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space## 2. What is the expected outcome and why- For copyin case:Kernel can recover from poison found where kernel is doing get_user() orcopy_from_user() if those places get an error return and the kernel return-EFAULT to the process instead of crashing. More specifily, MCE handlerchecks the fixup handler type to decide whether an in kernel #MC can berecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery codespecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.- For instr case:If a poison found while instruction fetching in user space, full recoveryis possible. User process takes #PF, Linux allocates a new page and fillsby reading from storage.## 3. What actually happens and why- For copyin case: kernel panic since v5.17Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a newextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated theextable fixup type for copy-from-user operations, changing it fromEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESShandling when posion found in get_user() or copy_from_user().- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE raceWhen an uncorrected memory error is consumed there is a race between theCMCI from the memory controller reporting an uncorrected error with a UCNAsignature, and the core reporting and SRAR signature machine check whenthe data is about to be consumed.### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]Prior to Icelake memory controllers reported patrol scrub events thatdetected a previously unseen uncorrected error in memory by signaling abroadcast machine check with an SRAO (Software Recoverable ActionOptional) signature in the machine check bank. This was overkill becauseit's not an urgent problem that no core is on the verge of consuming thatbad data. It's also found that multi SRAO UCE may cause nested MCEinterrupts and finally become an IERR.Hence, Intel downgrades the machine check bank signature of patrol scrubfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to#CMCI. Just to add to the confusion, Linux does take an action (inuc_decode_notifier()) to try to offline the page despite the UC*NA*signature name.### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]Having decided that CMCI/UCNA is the best action for patrol scrub errors,the memory controller uses it for reads too. But the memory controller isexecuting asynchronously from the core, and can't tell the differencebetween a "real" read and a speculative read. So it will do CMCI/UCNA ifan error is found in any read.Thus:1) Core is clever and thinks address A is needed soon, issues a speculative read.2) Core finds it is going to use address A soon after sending the read request3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.Quite often (because speculation has got better) the CMCI from the memorycontroller is delivered before the core is committed to the instructionreading address A, so the interrupt is taken, and Linux offlines the page(marking it as poison).## Why user process is killed for instr caseCommit 046545a661af ("mm/hwpoison: fix error page recovered but reported"not---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2019-19959 Severity: Moderate CVSS3 score: 5.4

Description: ext/misc/zipfile.c in SQLite 3.30.1 mishandles certain uses of INSERT INTO in situations involving embedded '\0' characters in filenames, leading to a memory-management error that can be detected by (for example) valgrind.

Packages affected:

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

CVE-2020-13630 Severity: Moderate CVSS3 score: 5.4

Description: ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature.

Packages affected:

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

CVE-2020-26555 Severity: Moderate CVSS3 score: 5.4

Description: Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification 1.0B through 5.2 may permit an unauthenticated nearby device to spoof the BD_ADDR of the peer device to complete pairing without knowledge of the PIN.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-22195 Severity: Moderate CVSS3 score: 5.4

Description: Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
python3-Jinja2 > 0-0 (version in image is 2.10.1-150000.3.21.1).

CVE-2025-48964 Severity: Moderate CVSS3 score: 5.4

Description: ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
iputils > 0-0 (version in image is 20211215-150400.3.22.1).

CVE-2019-14250 Severity: Moderate CVSS3 score: 5.3

Description: An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.32. simple_object_elf_match in simple-object-elf.c does not check for a zero shstrndx value, leading to an integer overflow and resultant heap-based buffer overflow.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
cpp > 0-0 (version in image is 7-3.9.1).

CVE-2019-19924 Severity: Moderate CVSS3 score: 5.3

Description: SQLite 3.30.1 mishandles certain parser-tree rewriting, related to expr.c, vdbeaux.c, and window.c. This is caused by incorrect sqlite3WindowRewrite() error handling.

Packages affected:

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

CVE-2022-21277 Severity: Moderate CVSS3 score: 5.3

Description: Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Oracle Java SE: 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2022-21283 Severity: Moderate CVSS3 score: 5.3

Description: Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2022-48910 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: ensure we call ipv6_mc_down() at most onceThere are two reasons for addrconf_notify() to be called with NETDEV_DOWN:either the network device is actually going down, or IPv6 was disabledon the interface.If either of them stays down while the other is toggled, we repeatedlycall the code for NETDEV_DOWN, including ipv6_mc_down(), while nevercalling the corresponding ipv6_mc_up() in between. This will cause anew entry in idev->mc_tomb to be allocated for each multicast groupthe interface is subscribed to, which in turn leaks one struct ifmcaddr6per nontrivial multicast group the interface is subscribed to.The following reproducer will leak at least $n objects:ip addr add ff2e::4242/32 dev eth0 autojoinsysctl -w net.ipv6.conf.eth0.disable_ipv6=1for i in $(seq 1 $n); do ip link set up eth0; ip link set down eth0doneJoining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting thesysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)can also be used to create a nontrivial idev->mc_list, which will theleak objects with the right up-down-sequence.Based on both sources for NETDEV_DOWN events the interface IPv6 stateshould be considered: - not ready if the network interface is not ready OR IPv6 is disabled for it - ready if the network interface is ready AND IPv6 is enabled for itThe functions ipv6_mc_up() and ipv6_down() should only be run when thisstate changes.Implement this by remembering when the IPv6 state is ready, and onlyrun ipv6_mc_down() if it actually changed from ready to not ready.The other direction (not ready -> ready) already works correctly, as: - the interface notification triggered codepath for NETDEV_UP / NETDEV_CHANGE returns early if ipv6 is disabled, and - the disable_ipv6=0 triggered codepath skips fully initializing the interface as long as addrconf_link_ready(dev) returns false - calling ipv6_mc_up() repeatedly does not leak anything

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49267 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: core: use sysfs_emit() instead of sprintf()sprintf() (still used in the MMC core for the sysfs output) is vulnerableto the buffer overflow. Use the new-fangled sysfs_emit() instead.Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-12243 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2024-22099 Severity: Moderate CVSS3 score: 5.3

Description: NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.This issue affects Linux kernel: v2.6.12-rc2.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-23848 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27008 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm: nv04: Fix out of bounds accessWhen Output Resource (dcb->or) value is assigned infabricate_dcb_output(), there may be out of bounds access todac_users array in case dcb->or is zero because ffs(dcb->or) isused as index there.The 'or' argument of fabricate_dcb_output() must be interpreted as anumber of bit to set, not value.Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36923 Severity: Moderate CVSS3 score: 5.3

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36933 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().syzbot triggered various splats (see [0] and links) by a crafted GSOpacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDPNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the innerprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), callsskb_mac_gso_segment() to invoke inner protocol GSO handlers.nsh_gso_segment() does the following for the original skb beforecalling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol.and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_lenThere are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header.It seems nsh_gso_segment() has never worked with outer headers so far.At the end of nsh_gso_segment(), the outer header must be restored forthe segmented skb, instead of the NSH header.To do that, let's calculate the outer header position relatively fromthe inner header and set skb->{data,mac_header,protocol} properly.[0]:BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50232 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()In the ad7124_write_raw() function, parameter val can potentiallybe zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()is called within ad7124_set_channel_odr(). The ad7124_write_raw()function is invoked through the sequence: iio_write_channel_raw() ->iio_write_channel_attribute() -> iio_channel_write(), with no checksin place to ensure val is non-zero.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-52615 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2024-52616 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2024-56597 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix shift-out-of-bounds in dbSplitWhen dmt_budmin is less than zero, it causes errorsin the later stages. Added a check to return an error beforehandin dbAllocCtl itself.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56636 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: do not assume mac header is set in geneve_xmit_skb()We should not assume mac header is set in output path.Use skb_eth_hdr() instead of eth_hdr() to fix the issue.sysbot reported the following : WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Modules linked in:CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ffRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56681 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - add error check in the ahash_hmac_init functionThe ahash_init functions may return fails. The ahash_hmac_init shouldnot return ok when ahash_init returns error. For an example, ahash_initwill return -ENOMEM when allocation memory is error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56756 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix freeing of the HMB descriptor tableThe HMB descriptor table is sized to the maximum number of descriptorsthat could be used for a given device, but __nvme_alloc_host_mem couldbreak out of the loop earlier on memory allocation failure and end upusing less descriptors than planned for, which leads to an incorrectsize passed to dma_free_coherent.In practice this was not showing up because the number of descriptorstends to be low and the dma coherent allocator always allocates andfrees at least a page.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: cls_flow: validate TCA_FLOW_RSHIFT attributesyzbot found that TCA_FLOW_RSHIFT attribute was not validated.Right shitfing a 32bit integer is undefined for large shift values.UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: ipv6_addrconf addrconf_dad_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix memory accounting leak.Matt Dowling reported a weird UDP memory usage issue.Under normal operation, the UDP memory usage reported in /proc/net/sockstatremains close to zero. However, it occasionally spiked to 524,288 pagesand never dropped. Moreover, the value doubled when the application wasterminated. Finally, it caused intermittent packet drops.We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577The application set INT_MAX to SO_RCVBUF, which triggered an integeroverflow in udp_rmem_release().When a socket is close()d, udp_destruct_common() purges its receivequeue and sums up skb->truesize in the queue. This total is calculatedand stored in a local unsigned integer variable.The total size is then passed to udp_rmem_release() to adjust memoryaccounting. However, because the function takes a signed integerargument, the total size can wrap around, causing an overflow.Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().When the issue occurred, the total in udp_destruct_common() was 2147484480(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and2) sets -2147479552 to amount. 3) reverts the wraparound, so we don'tsee a warning in inet_sock_destruct(). However, udp_memory_allocatedends up doubling at 4).Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves formemory_allocated"), memory usage no longer doubles immediately aftera socket is close()d because __sk_mem_reduce_allocated() caches theamount in udp_memory_per_cpu_fw_alloc. However, the next time a UDPsocket receives a packet, the subtraction takes effect, causing UDPmemory usage to double.This issue makes further memory allocation fail once the socket'ssk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packetdrops.To prevent this issue, let's use unsigned int for the calculation andcall sk_forward_alloc_add() only once for the small delta.Note that first_packet_length() also potentially has the same problem.[0]:from socket import *SO_RCVBUFFORCE = 33INT_MAX = (2 ** 31) - 1s = socket(AF_INET, SOCK_DGRAM)s.bind(('', 0))s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)c = socket(AF_INET, SOCK_DGRAM)c.connect(s.getsockname())data = b'a' * 100while True: c.send(data)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: The attack vector is a potential Denial of Service (DoS). The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.54.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: check that event count does not exceed event buffer lengthThe event count is read from register DWC3_GEVNTCOUNT.There is a check for the count being zero, but not for exceeding theevent buffer length.Check that event count does not exceed event buffer length,avoiding an out-of-bounds access when memcpy'ing the event.Crash log:Unable to handle kernel paging request at virtual address ffffffc0129be000pc : __memcpy+0x114/0x180lr : dwc3_check_event_buf+0xec/0x348x3 : 0000000000000030 x2 : 000000000000dfc4x1 : ffffffc0129be000 x0 : ffffff87aad60080Call trace:__memcpy+0x114/0x180dwc3_interrupt+0x24/0x34

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problemCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis problem is similar to the problem that thecommit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")fixes.The root cause is: the function ib_device_rename() renames the name withlock. But in the function kobject_uevent(), this name is accessed withoutlock protection at the same time.The solution is to add the lock protection when this name is accessed inthe function kobject_uevent().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: remove encap socket caching to avoid reference leakThe current scheme for caching the encap socket can lead to referenceleaks when we try to delete the netns.The reference chain is: xfrm_state -> enacp_sk -> netnsSince the encap socket is a userspace socket, it holds a reference onthe netns. If we delete the espintcp state (through flush orindividual delete) before removing the netns, the reference on thesocket is dropped and the netns is correctly deleted. Otherwise, thenetns may not be reachable anymore (if all processes within the nshave terminated), so we cannot delete the xfrm state to drop itsreference on the socket.This patch results in a small (~2% in my tests) performanceregression.A GC-type mechanism could be added for the socket cache, to clearreferences if the state hasn't been used "recently", but it's a lotmore complex than just not caching the socket.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Abort software beacon handling if disabledA malicious USB device can send a WMI_SWBA_EVENTID event from anath9k_htc-managed device before beaconing has been enabled. This causesa device-by-zero error in the driver, leading to either a crash or anout of bounds read.Prevent this by aborting the handling in ath9k_htc_swba() if beacons arenot enabled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: marvell/cesa - Handle zero-length skcipher requestsDo not access random memory for zero-length skcipher requests.Just return 0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling__xa_store() and __xa_erase() were used without holding the proper lock,which led to a lockdep warning due to unsafe RCU usage. This patchreplaces them with xa_store() and xa_erase(), which perform the necessarylocking internally. ============================= WARNING: suspicious RCPU usage 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted ----------------------------- ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by kworker/u136:0/219: at: process_one_work+0xbe4/0x15f0 process_one_work+0x75c/0x15f0 pagefault_mr+0x9a5/0x1390 [mlx5_ib] stack backtrace: CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] Call Trace: dump_stack_lvl+0xa8/0xc0 lockdep_rcu_suspicious+0x1e6/0x260 xas_create+0xb8a/0xee0 xas_store+0x73/0x14c0 __xa_store+0x13c/0x220 ? xa_store_range+0x390/0x390 ? spin_bug+0x1d0/0x1d0 pagefault_mr+0xcb5/0x1390 [mlx5_ib] ? _raw_spin_unlock+0x1f/0x30 mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib] process_one_work+0x7db/0x15f0 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x57d/0xcd0 ? rescuer_thread+0xc40/0xc40 kthread+0x3b3/0x800 ? kthread_is_per_cpu+0xb0/0xb0 ? lock_downgrade+0x680/0x680 ? do_raw_spin_lock+0x12d/0x270 ? spin_bug+0x1d0/0x1d0 ? finish_task_switch.isra.0+0x284/0x9e0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork+0x2d/0x70 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork_asm+0x11/0x20

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_{g2h,h2g} TOCTOUvsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.transport_{g2h,h2g} may become NULL after the NULL check.Introduce vsock_transport_local_cid() to protect from a potentialnull-ptr-deref.KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_find_cid+0x47/0x90Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix initialization of data for instructions that write to subdeviceSome Comedi subdevice instruction handlers are known to accessinstruction data elements beyond the first `insn->n` elements in somecases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functionsallocate at least `MIN_SAMPLES` (16) data elements to deal with this,but they do not initialize all of that. For Comedi instruction codesthat write to the subdevice, the first `insn->n` data elements arecopied from user-space, but the remaining elements are leftuninitialized. That could be a problem if the subdevice instructionhandler reads the uninitialized data. Ensure that the first`MIN_SAMPLES` elements are initialized before calling these instructionhandlers, filling the uncopied elements with 0. For`do_insnlist_ioctl()`, the same data buffer elements are used forhandling a list of instructions, so ensure the first `MIN_SAMPLES`elements are initialized for each instruction that writes to thesubdevice.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized data in insn_rw_emulate_bits()For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have`insn_read` and `insn_write` handler functions, but to have an`insn_bits` handler function for handling Comedi `INSN_BITS`instructions. In that case, the subdevice's `insn_read` and/or`insn_write` function handler pointers are set to point to the`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that thesupplied `data[0]` value is a valid copy from user memory. It will atleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements areallocated. However, if `insn->n` is 0 (which is allowable for`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may containuninitialized data, and certainly contains invalid data, possibly from adifferent instruction in the array of instructions handled by`do_insnlist_ioctl()`. This will result in an incorrect value beingwritten to the digital output channel (or to the digital input/outputchannel if configured as an output), and may be reflected in theinternal saved state of the channel.Fix it by returning 0 early if `insn->n` is 0, before reaching the codethat accesses `data[0]`. Previously, the function always returned 1 onsuccess, but it is supposed to be the number of data samples actuallyread or written up to `insn->n`, which is 0 in this case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das6402: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das16m1: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in cifs_oplock_breakA race condition can occur in cifs_oplock_break() leading to ause-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAFThe issue occurs when umount has already released its reference to thesuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), thisreleases the last reference, triggering the immediate cleanup of allinodes under RCU. However, cifs_oplock_break() continues to access thecinode after this point, resulting in use-after-free.Fix this by holding an extra reference to the superblock during theentire oplock break operation. This ensures that the superblock andits inodes remain valid until the oplock break completes.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

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

Description: urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).

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

Description: Uncontrolled Resource Consumption vulnerability in Apache Tomcat if an HTTP/2 client did not acknowledge the initial settings frame that reduces the maximum permitted concurrent streams.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106.The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Other EOL versions may also be affected.Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.

Packages affected:

tomcat > 0-0 (version in image is 9.0.108-150200.91.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

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

Description: xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
google-osconfig-agent > 0-0 (version in image is 20250416.02-150000.1.50.1).

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

Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
google-guest-agent > 0-0 (version in image is 20250506.01-150000.1.63.1).

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

Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-52493 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Drop chan lock before queuing buffersEnsure read and write locks for the channel are not taken in succession bydropping the read lock from parse_xfer_event() such that a callback givento client can potentially queue buffers and acquire the write lock in thatprocess. Any queueing of buffers should be done without channel read lockacquired as it can result in multiple locks and a soft lockup.[mani: added fixes tag and cc'ed stable]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52494 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Add alignment check for event ring read pointerThough we do check the event ring read pointer by "is_valid_ring_ptr"to make sure it is in the buffer range, but there is another risk thepointer may be not aligned. Since we are expecting event ring elementsare 128 bits(struct mhi_ring_element) aligned, an unaligned read pointercould lead to multiple issues like DoS or ring buffer memory corruption.So add a alignment check for event ring read pointer.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-2201 Severity: Moderate CVSS3 score: 5.1

Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-31142 Severity: Moderate CVSS3 score: 5.1

Description: Because of a logical error in XSA-407 (Branch Type Confusion), themitigation is not applied properly when it is intended to be used.XSA-434 (Speculative Return Stack Overflow) uses the sameinfrastructure, so is equally impacted.For more details, see: https://xenbits.xen.org/xsa/advisory-407.html https://xenbits.xen.org/xsa/advisory-434.html

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2024-36934 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:bna: ensure the copied buf is NUL terminatedCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes fromuserspace to that buffer. Later, we use sscanf on this buffer but we don'tensure that the string is terminated inside the buffer, this can lead toOOB read when using sscanf. Fix this issue by using memdup_user_nulinstead of memdup_user.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39476 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDINGXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang withsmall possibility, the root cause is exactly the same as commitbed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")However, Dan reported another hang after that, and junxiao investigatedthe problem and found out that this is caused by plugged bio can't issuefrom raid5d().Current implementation in raid5d() has a weird dependence:1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING;2) raid5d() handles IO in a deadloop, until all IO are issued;3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;This behaviour is introduce before v2.6, and for consequence, if othercontext hold 'reconfig_mutex', and md_check_recovery() can't updatesuper_block, then raid5d() will waste one cpu 100% by the deadloop, until'reconfig_mutex' is released.Refer to the implementation from raid1 and raid10, fix this problem byskipping issue IO if MD_SB_CHANGE_PENDING is still set aftermd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'is released. Meanwhile, the hang problem will be fixed as well.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39480 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22107 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()There are actually 2 problems:- deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds.- The memmove itself should move size - i - 1 elements, because the last element is out of bounds.The out-of-bounds element still remains out of bounds after beingaccessed, so the problem is only that we touch it, not that it becomesin active use. But I suppose it can lead to issues if the out-of-boundselement is part of an unmapped page.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-22231 Severity: Moderate CVSS3 score: 5.0

Description: Syndic cache directory creation is vulnerable to a directory traversal attack in salt project which can lead a malicious attacker to create an arbitrary directory on a Salt master.

Packages affected:

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

CVE-2024-40987 Severity: Moderate CVSS3 score: 5.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-20012 Severity: Moderate CVSS3 score: 4.9

Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38391 Severity: Moderate CVSS3 score: 4.9

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: do not index invalid pin_assignmentsA poorly implemented DisplayPort Alt Mode port partner can indicatethat its pin assignment capabilities are greater than the maximumvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_showwill cause a BRK exception due to an out of bounds array access.Prevent for loop in pin_assignment_show from accessinginvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAXvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loopcondition.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-7039 Severity: Moderate CVSS3 score: 4.9

Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2022-48906 Severity: Moderate CVSS3 score: 4.8

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Correctly set DATA_FIN timeout when number of retransmits is largeSyzkaller with UBSAN uncovered a scenario where a large number ofDATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FINtimeout calculation:================================================================================UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29shift exponent 32 is too large for 32-bit type 'unsigned int'CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Workqueue: events mptcp_workerCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline] __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 worker_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4/0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================================This change limits the maximum timeout by limiting the size of theshift, which keeps all intermediate values in-bounds.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-2283 Severity: Moderate CVSS3 score: 4.8

Description: A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.12.1).

CVE-2025-4373 Severity: Moderate CVSS3 score: 4.8

Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2021-47577 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:io-wq: check for wq exit after adding new worker task_workWe check IO_WQ_BIT_EXIT before attempting to create a new worker, andwq exit cancels pending work if we have any. But it's possible to havea race between the two, where creation checks exit finding it not set,but we're in the process of exiting. The exit side will cancel pendingcreation task_work, but there's a gap where we add task_work after we'vecanceled existing creations at exit time.Fix this by checking the EXIT bit post adding the creation task_work.If it's set, run the same cancelation that exit does.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48785 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: use rcu-safe version of ipv6_get_lladdr()Some time ago 8965779d2c0e ("ipv6,mcast: always hold idev->lock before mca_lock")switched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafeversion. That was OK, because idev->lock was held for these codepaths.In 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks wereremoved, so we probably need to restore the original rcu-safe call.Otherwise, we occasionally get a machine crashed/stalled with the followingin dmesg:[ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI[ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G O 5.15.19-cloudflare-2022.2.1 #1[ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV[ 3406.009552][T230589] Workqueue: mld mld_ifc_work[ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60[ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b[ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202[ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040[ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008[ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000[ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100[ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000[ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000[ 3406.138992][T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0[ 3406.162421][T230589] Call Trace:[ 3406.170235][T230589] [ 3406.177736][T230589] mld_newpack+0xfe/0x1a0[ 3406.186686][T230589] add_grhead+0x87/0xa0[ 3406.195498][T230589] add_grec+0x485/0x4e0[ 3406.204310][T230589] ? newidle_balance+0x126/0x3f0[ 3406.214024][T230589] mld_ifc_work+0x15d/0x450[ 3406.223279][T230589] process_one_work+0x1e6/0x380[ 3406.232982][T230589] worker_thread+0x50/0x3a0[ 3406.242371][T230589] ? rescuer_thread+0x360/0x360[ 3406.252175][T230589] kthread+0x127/0x150[ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40[ 3406.271287][T230589] ret_from_fork+0x22/0x30[ 3406.280812][T230589] [ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders][ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49052 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix unexpected zeroed page mapping with zram swapTwo processes under CLONE_VM cloning, user process can be corrupted byseeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed dataThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn'tincrease the refcount of swap slot at copy_mm so it couldn't catch upwhether it's safe or not to discard data from backing device. In thecase, only the lock it could rely on to synchronize swap slot freeing ispage table lock. Thus, this patch gets rid of the swap_slot_free_notifyfunction. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU BThe concern of the patch would increase memory consumption since itcould keep wasted memory with compressed form in zram as well asuncompressed form in address space. However, most of cases of zram usesno readahead and do_swap_page is followed by swap_free so it will freethe compressed form from in zram quickly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49072 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: Restrict usage of GPIO chip irq members before initializationGPIO chip irq members are exposed before they could be completelyinitialized and this leads to race conditions.One such issue was observed for the gc->irq.domain variable whichwas accessed through the I2C interface in gpiochip_to_irq() beforeit could be initialized by gpiochip_add_irqchip(). This resulted inKernel NULL pointer dereference.Following are the logs for reference :-kernel: Call Trace:kernel: gpiod_to_irq+0x53/0x70kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0kernel: i2c_acpi_get_irq+0xc0/0xd0kernel: i2c_device_probe+0x28a/0x2a0kernel: really_probe+0xf2/0x460kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0To avoid such scenarios, restrict usage of GPIO chip irq members beforethey are completely initialized.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49578 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_prot_sock.sysctl_ip_prot_sock is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49590 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_llm_reports.While reading sysctl_igmp_llm_reports, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50205 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext2: Add more validity checks for inode countsAdd checks verifying number of inodes stored in the superblock matchesthe number computed from number of inodes per group. Also verify we haveat least one block worth of inodes per group. This prevents crashes oncorrupted filesystems.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-0160 Severity: Moderate CVSS3 score: 4.7

Description: A deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-51767 Severity: Moderate CVSS3 score: 4.7

Description: OpenSSH through 10.0, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges. NOTE: this is disputed by the Supplier, who states "we do not consider it to be the application's responsibility to defend against platform architectural weaknesses."

Packages affected:

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

CVE-2023-52435 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent mss overflow in skb_segment()Once again syzbot is able to crash the kernel in skb_segment() [1]GSO_BY_FRAGS is a forbidden value, but unfortunately the followingcomputation in skb_segment() can reach it quite easily : mss = mss * partial_segs;65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead toa bad final result.Make sure to limit segmentation so that the new mss value is smallerthan GSO_BY_FRAGS.[1]general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53__skb_gso_segment+0x339/0x710 net/core/gso.c:124skb_gso_segment include/net/gso.h:83 [inline]validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338dev_queue_xmit include/linux/netdevice.h:3134 [inline]packet_xmit+0x257/0x380 net/packet/af_packet.c:276packet_snd net/packet/af_packet.c:3087 [inline]packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119sock_sendmsg_nosec net/socket.c:730 [inline]__sock_sendmsg+0xd5/0x180 net/socket.c:745__sys_sendto+0x255/0x340 net/socket.c:2190__do_sys_sendto net/socket.c:2202 [inline]__se_sys_sendto net/socket.c:2198 [inline]__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x63/0x6bRIP: 0033:0x7f8692032aa9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R0---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52587 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:IB/ipoib: Fix mcast list lockingReleasing the `priv->lock` while iterating the `priv->multicast_list` in`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` toremove the items while in the middle of iteration. If the mcast is removedwhile the lock was dropped, the for loop spins forever resulting in a hardlockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below) -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.)Fix this by keeping the lock held and changing to GFP_ATOMIC to preventeventual sleeps.Unfortunately we could not reproduce the lockup and confirm this fix butbased on the code review I think this fix should address such lockups.crash> bc 31PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"-- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018--- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967crash> rx ff646f199a8c7e68ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.workcrash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000(empty)crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000crash> b 8PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"-- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52589 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: rkisp1: Fix IRQ disable race issueIn rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks theinterrupts and then apparently assumes that the interrupt handler won'tbe running, and proceeds in the stop procedure. This is not the case, asthe interrupt handler can already be running, which would lead to theISP being disabled while the interrupt handler handling a capturedframe.This brings up two issues: 1) the ISP could be powered off while theinterrupt handler is still running and accessing registers, leading toboard lockup, and 2) the interrupt handler code and the code thatdisables the streaming might do things that conflict.It is not clear to me if 2) causes a real issue, but 1) can be seen witha suitable delay (or printk in my case) in the interrupt handler,leading to board lockup.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52643 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iio: core: fix memleak in iio_device_register_sysfsWhen iio_device_register_sysfs_group() fails, we shouldfree iio_dev_opaque->chan_attr_group.attrs to preventpotential memleak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52923 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: adapt set backend to use GC transaction APIUse the GC transaction API to replace the old and buggy gc API and thebusy mark approach.No set elements are removed from async garbage collection anymore,instead the _DEAD bit is set on so the set element is not visible fromlookup path anymore. Async GC enqueues transaction work that might beaborted and retried later.rbtree and pipapo set backends does not set on the _DEAD bit from thesync GC path since this runs in control plane path where mutex is held.In this case, set elements are deactivated, removed and then releasedvia RCU callback, sync GC never fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0639 Severity: Moderate CVSS3 score: 4.7

Description: A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0641 Severity: Moderate CVSS3 score: 4.7

Description: A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel's TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-10041 Severity: Moderate CVSS3 score: 4.7

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:

pam > 0-0 (version in image is 1.3.0-150000.6.86.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2024-20945 Severity: Moderate CVSS3 score: 4.7

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
java-11-openjdk > 0-0 (version in image is 11.0.28.0-150000.3.129.2).

CVE-2024-26989 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: hibernate: Fix level3 translation fault in swsusp_save()On arm64 machines, swsusp_save() faults if it attempts to accessMEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFIwhen booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable()-> kernel_page_present() assuming that a page is always present whencan_set_direct_map() is false (all of rodata_full,debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false),irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regionsshould not be saved during hibernation.This problem was introduced by changes to the pfn_valid() logic incommit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplifypfn_valid()").Similar to other architectures, drop the !can_set_direct_map() check inkernel_page_present() so that page_is_savable() skips such pages.[catalin.marinas@arm.com: rework commit message]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36286 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()syzbot reported that nf_reinject() could be called without rcu_read_lock() :WARNING: suspicious RCU usage6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not taintednet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 12 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172stack backtrace:CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36489 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:tls: fix missing memory barrier in tls_initIn tls_init(), a write memory barrier is missing, and store-storereordering may cause NULL dereference in tls_{setsockopt,getsockopt}.CPU0 CPU1----- -----// In tls_init()// In tls_ctx_create()ctx = kzalloc()ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)// In update_sk_prot()WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3)In the above scenario, when (1) and (2) are reordered, (3) can observethe NULL value of ctx->sk_proto, causing NULL dereference.To fix it, we rely on rcu_assign_pointer() which implies the releasebarrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto isinitialized, we can ensure that ctx->sk_proto are visible whenchanging sk->sk_prot.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36924 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes thehbalock. Thus, lpfc_worker_wake_up() should not be called while holding thehbalock to avoid potential deadlock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36952 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move NPIV's transport unregistration to after resource clean upThere are cases after NPIV deletion where the fabric switch still believesthe NPIV is logged into the fabric. This occurs when a vport isunregistered before the Remove All DA_ID CT and LOGO ELS are sent to thefabric.Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs includingthe fabric D_ID, removes the last ndlp reference and frees the ndlp rportobject. This sometimes causes the race condition where the final DA_ID andLOGO are skipped from being sent to the fabric switch.Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_IDand LOGO are sent.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36954 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix a possible memleak in tipc_buf_append__skb_linearize() doesn't free the skb when it fails, so move'*buf = NULL' after __skb_linearize(), so that the skb can befreed on the err path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38544 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix seg fault in rxe_comp_queue_pktIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to theresp_pkts queue and then a decision is made whether to run the completertask inline or schedule it. Finally the skb is dereferenced to bump a 'hw'performance counter. This is wrong because if the completer task isalready running in a separate thread it may have already processed the skband freed it which can cause a seg fault. This has been observedinfrequently in testing at high scale.This patch fixes this by changing the order of enqueuing the packet untilafter the counter is accessed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38553 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: remove .ndo_poll_controller to avoid deadlocksThere is a deadlock issue found in sungem driver, please refer to thecommit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoiddeadlocks"). The root cause of the issue is that netpoll is in atomiccontext and disable_irq() is called by .ndo_poll_controller interfaceof sungem driver, however, disable_irq() might sleep. After analyzingthe implementation of fec_poll_controller(), the fec driver should havethe same issue. Due to the fec driver uses NAPI for TX completions, the.ndo_poll_controller is unnecessary to be implemented in the fec driver,so fec_poll_controller() can be safely removed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38557 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Reload only IB representors upon lag disable/enableOn lag disable, the bond IB device along with all of itsrepresentors are destroyed, and then the slaves' representors get reloaded.In case the slave IB representor load fails, the eswitch error flowunloads all representors, including ethernet representors, where thenetdevs get detached and removed from lag bond. Such flow is inaccurateas the lag driver is not responsible for loading/unloading ethernetrepresentors. Furthermore, the flow described above begins by holdinglag lock to prevent bond changes during disable flow. However, whenreaching the ethernet representors detachment from lag, the lag lock isrequired again, triggering the following deadlock:Call trace:__switch_to+0xf4/0x148__schedule+0x2c8/0x7d0schedule+0x50/0xe0schedule_preempt_disabled+0x18/0x28__mutex_lock.isra.13+0x2b8/0x570__mutex_lock_slowpath+0x1c/0x28mutex_lock+0x4c/0x68mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]mlx5_disable_lag+0x130/0x138 [mlx5_core]mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lockmlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]devlink_nl_cmd_eswitch_set_doit+0xdc/0x180genl_family_rcv_msg_doit.isra.17+0xe8/0x138genl_rcv_msg+0xe4/0x220netlink_rcv_skb+0x44/0x108genl_rcv+0x40/0x58netlink_unicast+0x198/0x268netlink_sendmsg+0x1d4/0x418sock_sendmsg+0x54/0x60__sys_sendto+0xf4/0x120__arm64_sys_sendto+0x30/0x40el0_svc_common+0x8c/0x120do_el0_svc+0x30/0xa0el0_svc+0x20/0x30el0_sync_handler+0x90/0xb8el0_sync+0x160/0x180Thus, upon lag enable/disable, load and unload only the IB representorsof the slaves preventing the deadlock mentioned above.While at it, refactor the mlx5_esw_offloads_rep_load() function to havea static helper method for its internal logic, in symmetry with therepresentor unload design.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38590 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Modify the print level of CQE errorToo much print may lead to a panic in kernel. Change ibdev_err() toibdev_err_ratelimited(), and change the printing level of cqe dumpto debug level.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38591 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix deadlock on SRQ async events.xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/xa_erase_irq() to avoid deadlock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38600 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: Fix deadlocks with kctl removals at disconnectionIn snd_card_disconnect(), we set card->shutdown flag at the beginning,call callbacks and do sync for card->power_ref_sleep waiters at theend. The callback may delete a kctl element, and this can lead to adeadlock when the device was in the suspended state. Namely:* A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem.* The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks.An easy fix is to wake up sleepers before processing the driverdisconnect callbacks but right after setting the card->shutdown flag.Then all sleepers will abort immediately, and the code flows again.So, basically this patch moves the wait_event() call at the righttiming. While we're at it, just to be sure, call wait_event_all()instead of wait_event(), although we don't use exclusive events onthis queue for now.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38602 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix reference count leak issues of ax25_devThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a referencecount leak issue of the object "ax25_dev".Memory leak issue in ax25_addr_ax25dev():The reference count of the object "ax25_dev" can be increased multipletimes in ax25_addr_ax25dev(). This will cause a memory leak.Memory leak issues in ax25_dev_device_down():The reference count of ax25_dev is set to 1 in ax25_dev_device_up() andthen increase the reference count when ax25_dev is added to ax25_dev_list.As a result, the reference count of ax25_dev is 2. But when the device isshutting down. The ax25_dev_device_down() drops the reference count onceor twice depending on if we goto unlock_put or not, which will causememory leak.As for the issue of ax25_addr_ax25dev(), it is impossible for one pointerto be on a list twice. So add a break in ax25_addr_ax25dev(). As for theissue of ax25_dev_device_down(), increase the reference count of ax25_devonce in ax25_dev_device_up() and decrease the reference count of ax25_devafter it is removed from the ax25_dev_list.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38618 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: Set lower bound of start tick timeCurrently ALSA timer doesn't have the lower limit of the start ticktime, and it allows a very small size, e.g. 1 tick with 1ns resolutionfor hrtimer. Such a situation may lead to an unexpected RCU stall,where the callback repeatedly queuing the expire update, as reportedby fuzzer.This patch introduces a sanity check of the timer start tick time, sothat the system returns an error when a too small start size is set.As of this patch, the lower limit is hard-coded to 100us, which issmall enough but can still work somehow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39276 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()Syzbot reports a warning as follows:============================================WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290Modules linked in:CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419Call Trace: ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327[...]============================================This is because when finding an entry in ext4_xattr_block_cache_find(), ifext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grownin the __entry_find(), won't be put away, and eventually trigger the aboveissue in mb_cache_destroy() due to reference count leakage.So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39500 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:sock_map: avoid race between sock_map_close and sk_psock_putsk_psock_get will return NULL if the refcount of psock has gone to 0, whichwill happen when the last call of sk_psock_put is done. However,sk_psock_drop may not have finished yet, so the close callback will stillpoint to sock_map_close despite psock being NULL.This can be reproduced with a thread deleting an element from the sock map,while the second one creates a socket, adds it to the map and closes it.That will trigger the WARN_ON_ONCE:------------[ cut here ]------------WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701Modules linked in:CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0Call Trace: unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fb37d618070Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7cRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Use sk_psock, which will only check that the pointer is not been set toNULL yet, which should only happen after the callbacks are restored. If,then, a reference can still be gotten, we may call sk_psock_stop and cancelpsock->work.As suggested by Paolo Abeni, reorder the condition so the control flow isless convoluted.After that change, the reproducer does not trigger the WARN_ON_ONCEanymore.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39501 Severity: Moderate CVSS3 score: 4.7

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39507 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash problem in concurrent scenarioWhen link status change, the nic driver need to notify the rocedriver to handle this event, but at this time, the roce drivermay uninit, then cause kernel crash.To fix the problem, when link status change, need to checkwhether the roce registered, and when uninit, need to wait linkupdate finish.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40965 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: lpi2c: Avoid calling clk_get_rate during transferInstead of repeatedly calling clk_get_rate for each transfer, lockthe clock rate and cache the value.A deadlock has been observed while adding tlv320aic32x4 audio codec tothe system. When this clock provider adds its clock, the clk mutex islocked already, it needs to access i2c, which in return needs the mutexfor clk_get_rate as well.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40966 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:tty: add the option to have a tty reject a new ldisc... and use it to limit the virtual terminals to just N_TTY. They arekind of special, and in particular, the "con_write()" routine violatesthe "writes cannot sleep" rule that some ldiscs rely on.This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659when N_GSM has been attached to a virtual console, and gsmld_write()calls con_write() while holding a spinlock, and con_write() then triesto get the console lock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40967 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:serial: imx: Introduce timeout when waiting on transmitter emptyBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potentialdeadlock.In case of the timeout, there is not much we can do, so we simply ignorethe transmitter state and optimistically try to continue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40980 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: replace spin_lock by raw_spin_locktrace_drop_common() is called with preemption disabled, and it acquiresa spin_lock. This is problematic for RT kernels because spin_locks aresleeping locks in this configuration, which causes the following splat:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47preempt_count: 1, expected: 0RCU nest depth: 2, expected: 25 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290irq event stamp: 139909hardirqs last enabled at (139908): [] _raw_spin_unlock_irqrestore+0x63/0x80hardirqs last disabled at (139909): [] trace_drop_common.constprop.0+0x26d/0x290softirqs last enabled at (139892): [] __local_bh_enable_ip+0x103/0x170softirqs last disabled at (139898): [] rcu_cpu_kthread+0x93/0x1f0Preemption disabled at:[] rt_mutex_slowunlock+0xab/0x2e0CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022Call Trace: dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520...trace_drop_common() also disables interrupts, but this is a minor issuebecause we could easily replace it with a local_lock.Replace the spin_lock with raw_spin_lock to avoid sleeping in atomiccontext.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42079 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix NULL pointer dereference in gfs2_log_flushIn gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flushlock to provide exclusion against gfs2_log_flush().In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL beforedereferencing it. Otherwise, we could run into a NULL pointerdereference when outstanding glock work races with an unmount(glock_work_func -> run_queue -> do_xmote -> inode_go_sync ->gfs2_log_flush).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42115 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:jffs2: Fix potential illegal address access in jffs2_free_inodeDuring the stress testing of the jffs2 file system,the followingabnormal printouts were found:[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948[ 2430.649622] Mem abort info:[ 2430.649829] ESR = 0x96000004[ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits[ 2430.650564] SET = 0, FnV = 0[ 2430.650795] EA = 0, S1PTW = 0[ 2430.651032] FSC = 0x04: level 0 translation fault[ 2430.651446] Data abort info:[ 2430.651683] ISV = 0, ISS = 0x00000004[ 2430.652001] CM = 0, WnR = 0[ 2430.652558] [0069696969696948] address between user and kernel address ranges[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33[ 2430.655008] Hardware name: linux,dummy-virt (DT)[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 2430.656142] pc : kfree+0x78/0x348[ 2430.656630] lr : jffs2_free_inode+0x24/0x48[ 2430.657051] sp : ffff800009eebd10[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000[ 2430.664217] Call trace:[ 2430.664528] kfree+0x78/0x348[ 2430.664855] jffs2_free_inode+0x24/0x48[ 2430.665233] i_callback+0x24/0x50[ 2430.665528] rcu_do_batch+0x1ac/0x448[ 2430.665892] rcu_core+0x28c/0x3c8[ 2430.666151] rcu_core_si+0x18/0x28[ 2430.666473] __do_softirq+0x138/0x3cc[ 2430.666781] irq_exit+0xf0/0x110[ 2430.667065] handle_domain_irq+0x6c/0x98[ 2430.667447] gic_handle_irq+0xac/0xe8[ 2430.667739] call_on_irq_stack+0x28/0x54The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field ofthe jffs_inode_info structure. It was found that all variables in the jffs_inode_infostructure were 5a5a5a5a, except for the first member sem. It is suspected that thesevariables are not initialized because they were set to 5a5a5a5a during memory testing,which is meant to detect uninitialized memory.The sem variable is initialized in thefunction jffs2_i_init_once, while other members are initialized inthe function jffs2_init_inode_info.The function jffs2_init_inode_info is called after iget_locked,but in the iget_locked function, the destroy_inode process is triggered,which releases the inode and consequently, the target member of the inodeis not initialized.In concurrent high pressure scenarios, iget_lockedmay enter the destroy_inode branch as described in the code.Since the destroy_inode functionality of jffs2 only releases the target,the fix method is to set target to NULL in jffs2_i_init_once.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44963 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() when freeing tree block after errorWhen freeing a tree block, at btrfs_free_tree_block(), if we fail tocreate a delayed reference we don't deal with the error and just do aBUG_ON(). The error most likely to happen is -ENOMEM, and we have acomment mentioning that only -ENOMEM can happen, but that is not true,because in case qgroups are enabled any error returned frombtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returnedfrom btrfs_search_slot() for example) can be propagated back tobtrfs_free_tree_block().So stop doing a BUG_ON() and return the error to the callers and makethem abort the transaction to prevent leaking space. Syzbot wastriggering this, likely due to memory allocation failure injection.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45828 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Mask ring interrupts before ring stop requestBus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt whenthe ring is being stopped. Depending on timing between ring stop requestcompletion, interrupt handler removal and code execution this may leadto a NULL pointer dereference in hci_dma_irq_handler() if it gets to runafter the io_data pointer is set to NULL in hci_dma_cleanup().Prevent this my masking the ring interrupts before ring stop request.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46678 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: change ipsec_lock from spin lock to mutexIn the cited commit, bond->ipsec_lock is added to protect ipsec_list,hence xdo_dev_state_add and xdo_dev_state_delete are called insidethis lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,"scheduling while atomic" will be triggered when changing bond'sactive slave.[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200[ 101.055726] Modules linked in:[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1[ 101.058760] Hardware name:[ 101.059434] Call Trace:[ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60[ 101.061275] __schedule_bug+0x4e/0x60[ 101.061682] __schedule+0x612/0x7c0[ 101.062078] ? __mod_timer+0x25c/0x370[ 101.062486] schedule+0x25/0xd0[ 101.062845] schedule_timeout+0x77/0xf0[ 101.063265] ? asm_common_interrupt+0x22/0x40[ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10[ 101.064215] __wait_for_common+0x87/0x190[ 101.064648] ? usleep_range_state+0x90/0x90[ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core][ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core][ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core][ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core][ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding][ 101.067738] ? kmalloc_trace+0x4d/0x350[ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core][ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core][ 101.069312] bond_change_active_slave+0x392/0x900 [bonding][ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding][ 101.070454] __bond_opt_set+0xa6/0x430 [bonding][ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding][ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding][ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding][ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0[ 101.073033] vfs_write+0x2d8/0x400[ 101.073416] ? alloc_fd+0x48/0x180[ 101.073798] ksys_write+0x5f/0xe0[ 101.074175] do_syscall_64+0x52/0x110[ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only calledfrom bond_change_active_slave, which requires holding the RTNL lock.And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm statexdo_dev_state_add and xdo_dev_state_delete APIs, which are in usercontext. So ipsec_lock doesn't have to be spin lock, change it tomutex, and thus the above issue can be resolved.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46750 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Add missing bridge lock to pci_bus_lock()One of the true positives that the cfg_access_lock lockdep effortidentified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120Where pci_reset_bus() users are triggering unlocked secondary bus resets.Ironically pci_bus_reset(), several calls down from pci_reset_bus(), usespci_bus_lock() before issuing the reset which locks everything *but* thebridge itself.For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge);to pci_reset_function() for the "bus" and "cxl_bus" reset cases, addpci_dev_lock() for @bus->self to pci_bus_lock().[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47141 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: Use sequential access to access desc->pinmux dataWhen two client of the same gpio call pinctrl_select_state() for thesame functionality, we are seeing NULL pointer issue while accessingdesc->mux_owner.Let's say two processes A, B executing in pin_request() for the same pinand process A updates the desc->mux_usecount but not yet updated thedesc->mux_owner while process B see the desc->mux_usecount which gotupdated by A path and further executes strcmp and while accessingdesc->mux_owner it crashes with NULL pointer.Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B)pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } }

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47679 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vfs: fix race between evice_inodes() and find_inode()&iput()Hi, allRecently I noticed a bug[1] in btrfs, after digged it intoand I believe it'a race in vfs.Let's assume there's a inode (ie ino 261) with i_count 1 iscalled by iput(), and there's a concurrent thread callinggeneric_shutdown_super().cpu0: cpu1:iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock()// note here: the inode 261// was still at sb list and hash list,// and I_FREEING|I_WILL_FREE was not been setbtrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEINGiput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()Now, we have two threads simultaneously evictingthe same inode, which may trigger the BUG(inode->i_state & I_CLEAR)statement both within clear_inode() and iput().To fix the bug, recheck the inode->i_count after holding i_lock.Because in the most scenarios, the first check is valid, andthe overhead of spin_lock() can be reduced.If there is any misunderstanding, please let me know, thanks.[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()return false when I reproduced the bug.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49868 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a NULL pointer dereference when failed to start a new trasacntion[BUG]Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[CAUSE]The allocation failure happens at the start_transaction() insideprepare_to_relocate(), and during the error handling we callunset_reloc_control(), which makes fs_info->balance_ctl to be NULL.Then we continue the error path cleanup in btrfs_balance() by callingreset_balance_state() which will call del_balance_item() to fully deletethe balance item in the root tree.However during the small window between set_reloc_contrl() andunset_reloc_control(), we can have a subvolume tree update and created areloc_root for that subvolume.Then we go into the final btrfs_commit_transaction() ofdel_balance_item(), and into btrfs_update_reloc_root() insidecommit_fs_roots().That function checks if fs_info->reloc_ctl is in the merge_reloc_treestage, but since fs_info->reloc_ctl is NULL, it results a NULL pointerdereference.[FIX]Just add extra check on fs_info->reloc_ctl insidebtrfs_update_reloc_root(), before checkingfs_info->reloc_ctl->merge_reloc_tree.That DEAD_RELOC_TREE handling is to prevent further modification to thereloc tree during merge stage, but since there is no reloc_ctl at all,we do not need to bother that.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49933 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk_iocost: fix more out of bound shiftsRecently running UBSAN caught few out of bound shifts in theioc_forgive_debts() function:UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned longlong')...UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned longlong')...Call Trace:dump_stack_lvl+0xca/0x130__ubsan_handle_shift_out_of_bounds+0x22c/0x280? __lock_acquire+0x6441/0x7c10ioc_timer_fn+0x6cec/0x7750? blk_iocost_init+0x720/0x720? call_timer_fn+0x5d/0x470call_timer_fn+0xfa/0x470? blk_iocost_init+0x720/0x720__run_timer_base+0x519/0x700...Actual impact of this issue was not identified but I propose to fix theundefined behaviour.The proposed fix to prevent those out of bound shifts consist ofprecalculating exponent before using it the shift operations by takingmin value from the actual exponent and maximum possible number of bits.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50006 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix i_data_sem unlock order in ext4_ind_migrate()Fuzzing reports a possible deadlock in jbd2_log_wait_commit.This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to requiresynchronous updates because the file descriptor is opened with O_SYNC.This can lead to the jbd2_journal_stop() function callingjbd2_might_wait_for_commit(), potentially causing a deadlock if theEXT4_IOC_MIGRATE call races with a write(2) system call.This problem only arises when CONFIG_PROVE_LOCKING is enabled. In thiscase, the jbd2_might_wait_for_commit macro locks jbd2_handle in thejbd2_journal_stop function while i_data_sem is locked. This triggerslockdep because the jbd2_journal_start function might also lock the samejbd2_handle simultaneously.Found by Linux Verification Center (linuxtesting.org) with syzkaller.Rule: add

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50138 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Use raw_spinlock_t in ringbufThe function __bpf_ringbuf_reserve is invoked from a tracepoint, whichdisables preemption. Using spinlock_t in this context can lead to a"sleep in atomic" warning in the RT variant. This issue is illustratedin the example below:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progspreempt_count: 1, expected: 0RCU nest depth: 1, expected: 1INFO: lockdep is turned off.Preemption disabled at:[] migrate_enable+0xc0/0x39cCPU: 7 PID: 556208 Comm: test_progs Tainted: GHardware name: Qualcomm SA8775P Ride (DT)Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180Switch the spinlock to raw_spinlock_t to avoid this error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50146 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Don't call cleanup on profile rollback failureWhen profile rollback fails in mlx5e_netdev_change_profile, the netdevprofile var is left set to NULL. Avoid a crash when unloading the driverby not calling profile->cleanup in such a case.This was encountered while testing, with the original trigger thatthe wq rescuer thread creation got interrupted (presumably due toCtrl+C-ing modprobe), which gets converted to ENOMEM (-12) bymlx5e_priv_init, the profile rollback also fails for the same reason(signal still active) so the profile is left as NULL, leading to a crashlater in _mlx5e_remove. [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12 [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 745.538222] #PF: supervisor read access in kernel mode [ 745.551290] Call Trace: [ 745.551590] [ 745.551866] ? __die+0x20/0x60 [ 745.552218] ? page_fault_oops+0x150/0x400 [ 745.555307] ? exc_page_fault+0x79/0x240 [ 745.555729] ? asm_exc_page_fault+0x22/0x30 [ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core] [ 745.556698] auxiliary_bus_remove+0x18/0x30 [ 745.557134] device_release_driver_internal+0x1df/0x240 [ 745.557654] bus_remove_device+0xd7/0x140 [ 745.558075] device_del+0x15b/0x3c0 [ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core] [ 745.559112] mlx5_unregister_device+0x34/0x50 [mlx5_core] [ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core] [ 745.560203] remove_one+0x4e/0xd0 [mlx5_core] [ 745.560694] pci_device_remove+0x39/0xa0 [ 745.561112] device_release_driver_internal+0x1df/0x240 [ 745.561631] driver_detach+0x47/0x90 [ 745.562022] bus_remove_driver+0x84/0x100 [ 745.562444] pci_unregister_driver+0x3b/0x90 [ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core] [ 745.563415] __x64_sys_delete_module+0x14d/0x2f0 [ 745.563886] ? kmem_cache_free+0x1b0/0x460 [ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190 [ 745.564825] do_syscall_64+0x6d/0x140 [ 745.565223] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 745.565725] RIP: 0033:0x7f1579b1288b

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50163 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make sure internal and UAPI bpf_redirect flags don't overlapThe bpf_redirect_info is shared between the SKB and XDP redirect paths,and the two paths use the same numeric flag values in the ri->flagsfield (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means thatif skb bpf_redirect_neigh() is used with a non-NULL params argument and,subsequently, an XDP redirect is performed using the samebpf_redirect_info struct, the XDP path will get confused and end upcrashing, which syzbot managed to trigger.With the stack-allocated bpf_redirect_info, the structure is no longershared between the SKB and XDP paths, so the crash doesn't happenanymore. However, different code paths using identically-numbered flagvalues in the same struct field still seems like a bit of a mess, sothis patch cleans that up by moving the flag definitions together andredefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlapwith the flags used for XDP. It also adds a BUILD_BUG_ON() check to makesure the overlap is not re-introduced by mistake.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50184 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_pmem: Check device status before requesting flushIf a pmem device is in a bad status, the driver side could wait forhost ack forever in virtio_pmem_flush(), causing the system to hang.So add a status check in the beginning of virtio_pmem_flush() to returnearly if the device is not activated.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50275 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/sve: Discard stale CPU state when handling SVE trapsThe logic for handling SVE traps manipulates saved FPSIMD/SVE stateincorrectly, and a race with preemption can result in a task havingTIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SVE traps enabled). This has been observed to resultin warnings from do_sve_acc() where SVE traps are not expected whileTIF_SVE is set:| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/The race can occur when the SVE trap handler is preempted before andafter manipulating the saved FPSIMD/SVE state, starting and ending onthe same CPU, e.g.| void do_sve_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */|| sve_init_regs() {| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| ...| } else {| fpsimd_to_sve(current);| current->thread.fp_type = FP_STATE_SVE;| }| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SVE traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53169 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fabrics: fix kernel crash while shutting down controllerThe nvme keep-alive operation, which executes at a periodic interval,could potentially sneak in while shutting down a fabric controller.This may lead to a race between the fabric controller admin queuedestroy code path (invoked while shutting down controller) and hw/hctxqueue dispatcher called from the nvme keep-alive async request queuingoperation. This race could lead to the kernel crash shown below:Call Trace: autoremove_wake_function+0x0/0xbc (unreliable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18While shutting down fabric controller, if nvme keep-alive request sneaksin then it would be flushed off. The nvme_keep_alive_end_io function isthen invoked to handle the end of the keep-alive operation whichdecrements the admin->q_usage_counter and assuming this is the last/onlyrequest in the admin queue then the admin->q_usage_counter becomes zero.If that happens then blk-mq destroy queue operation (blk_mq_destroy_queue()) which could be potentially running simultaneously on anothercpu (as this is the controller shutdown code path) would forwardprogress and deletes the admin queue. So, now from this point onwardwe are not supposed to access the admin queue resources. However theissue here's that the nvme keep-alive thread running hw/hctx queuedispatch operation hasn't yet finished its work and so it could stillpotentially access the admin queue resource while the admin queue hadbeen already deleted and that causes the above crash.The above kernel crash is regression caused due to changes implementedin commit a54a93d0e359 ("nvme: move stopping keep-alive intonvme_uninit_ctrl()"). Ideally we should stop keep-alive before destroying the admin queue and freeing the admin tagset so that it wouldn't sneakin during the shutdown operation. However we removed the keep alive stopoperation from the beginning of the controller shutdown code path in commita54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()")and added it under nvme_uninit_ctrl() which executes very late in theshutdown code path after the admin queue is destroyed and its tagset isremoved. So this change created the possibility of keep-alive sneaking inand interfering with the shutdown operation and causing observed kernelcrash.To fix the observed crash, we decided to move nvme_stop_keep_alive() fromnvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensurethat we don't forward progress and delete the admin queue until the keep-alive operation is finished (if it's in-flight) or cancelled and that wouldhelp contain the race condition explained above and hence avoid the crash.Moving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead ofadding nvme_stop_keep_alive() to the beginning of the controller shutdowncode path in nvme_stop_ctrl(), as was the case earlier before commita54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"),would help save one callsite of nvme_stop_keep_alive().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53176 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: During unmount, ensure all cached dir instances drop their dentryThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) canrace with various cached directory operations, which ultimately resultsin dentries not being dropped and these kernel BUGs:BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]VFS: Busy inodes after unmount of cifs (cifs)------------[ cut here ]------------kernel BUG at fs/super.c:661!This happens when a cfid is in the process of being cleaned up when, andhas been removed from the cfids->entries list, including:- Receiving a lease break from the server- Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list- The laundromat thread decides to expire an old cfid.To solve these problems, dropping the dentry is done in queued work donein a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()flushes that workqueue after it drops all the dentries of which it'saware. This is a global workqueue (rather than scoped to a mount), butthe queued work is minimal.The final cleanup work for cleaning up a cfid is performed via workqueued in the serverclose_wq workqueue; this is done separate fromdropping the dentries so that close_all_cached_dirs() doesn't block onany server operations.Both of these queued works expect to invoked with a cfid reference anda tcon reference to avoid those objects from being freed while the workis ongoing.While we're here, add proper locking to close_all_cached_dirs(), andlocking around the freeing of cfid->dentry.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53178 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: Don't leak cfid when reconnect races with open_cached_diropen_cached_dir() may either race with the tcon reconnection even beforecompound_send_recv() or directly trigger a reconnection viaSMB2_open_init() or SMB_query_info_init().The reconnection process invokes invalidate_all_cached_dirs() viacifs_mark_open_files_invalid(), which removes all cfids from thecfids->entries list but doesn't drop a ref if has_lease isn't true. Thisresults in the currently-being-constructed cfid not being on the list,but still having a refcount of 2. It leaks if returned fromopen_cached_dir().Fix this by setting cfid->has_lease when the ref is actually taken; thecfid will not be used by other threads until it has a valid time.Addresses these kmemleaks:unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] open_cached_dir+0x993/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eunreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eAnd addresses these BUG splats when unmounting the SMB filesystem:BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100Modules linked in:CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020RIP: 0010:umount_check+0xd0/0x100Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41RSP: 0018:ffff88811cc27978 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20baeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0Call Trace: d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f23bfb93ae7Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53218 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix race in concurrent f2fs_stop_gc_threadIn my test case, concurrent calls to f2fs shutdown report the followingstack trace: Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_general_protection+0x24b/0x5c0 ? asm_exc_general_protection+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe root cause is a race condition in f2fs_stop_gc_thread() called fromdifferent f2fs shutdown paths: [CPU0] [CPU1] ---------------------- ----------------------- f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAFThe commit c7f114d864ac ("f2fs: fix to avoid use-after-free inf2fs_stop_gc_thread()") attempted to fix this issue by using a readsemaphore to prevent races between shutdown and remount threads, butit fails to prevent all race conditions.Fix it by converting to write lock of s_umount in f2fs_do_shutdown().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53224 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Move events notifier registration to be after device registrationMove pkey change work initialization and cleanup from device resourcesstage to notifier stage, since this is the stage which handles this workevents.Fix a race between the device deregistration and pkey change work by movingMLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order toensure that the notifier is deregistered before the device during cleanup.Which ensures there are no works that are being executed after thedevice has already unregistered which can cause the panic below.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023Workqueue: events pkey_change_handler [mlx5_ib]RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]process_one_work+0x1e8/0x3c0worker_thread+0x50/0x3b0? rescuer_thread+0x380/0x380kthread+0x149/0x170? set_kthread_struct+0x50/0x50ret_from_fork+0x22/0x30Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]CR2: 0000000000000000---[ end trace f6f8be4eae12f7bc ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-54683 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: IDLETIMER: Fix for possible ABBA deadlockDeletion of the last rule referencing a given idletimer may happen atthe same time as a read of its file in sysfs:| ======================================================| WARNING: possible circular locking dependency detected| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted| ------------------------------------------------------| iptables/3303 is trying to acquire lock:| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20|| but task is already holding lock:| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]|| which lock already depends on the new lock.A simple reproducer is:| #!/bin/bash|| while true; do| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| done &| while true; do| cat /sys/class/xt_idletimer/timers/testme >/dev/null| doneAvoid this by freeing list_mutex right after deleting the element fromthe list, then continuing with the teardown.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-55916 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: util: Avoid accessing a ringbuffer not initialized yetIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer isfully initialized, we can hit the panic below:hv_utils: Registering HyperV Utility Driverhv_vmbus: registering driver hv_utils...BUG: kernel NULL pointer dereference, address: 0000000000000000CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1RIP: 0010:hv_pkt_iter_first+0x12/0xd0Call Trace:... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 asm_sysvec_hyperv_stimer0... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_readThis can happen because the KVP/VSS channel callback can be invokedeven before the channel is fully opened:1) as soon as hv_kvp_init() -> hvutil_transport_init() creates/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately andregister itself to the driver by writing a message KVP_OP_REGISTER1 to thefile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) andreading the file for the driver's response, which is handled byhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().2) the problem with kvp_register_done() is that it can cause thechannel callback to be called even before the channel is fully opened,and when the channel callback is starting to run, util_probe()->vmbus_open() may have not initialized the ringbuffer yet, so thecallback can hit the panic of NULL pointer dereference.To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in__vmbus_open(), just before the first hv_ringbuffer_init(), and then weunload and reload the driver hv_utils, and run the daemon manually withinthe 10 seconds.Fix the panic by reordering the steps in util_probe() so the char deventry used by the KVP or VSS daemon is not created until aftervmbus_open() has completed. This reordering prevents the race conditionfrom happening.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56568 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu: Defer probe of clients after smmu device boundNull pointer dereference occurs due to a race between smmudriver probe and client driver probe, when of_dma_configure()for client is called after the iommu_device_register() for smmu driverprobe has executed but before the driver_bound() for smmu driverhas been called.Following is how the race occurs:T1:Smmu device probe T2: Client device probereally_probe()arm_smmu_device_probe()iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamid_mask */driver_bound() klist_add_tail()When this null smmu pointer is dereferenced later inarm_smmu_probe_device, the device crashes.Fix this by deferring the probe of the client deviceuntil the smmu device has bound to the arm smmu driver.[will: Add comment]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56587 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:leds: class: Protect brightness_show() with led_cdev->led_access mutexThere is NULL pointer issue observed if from Process A where hid devicebeing added which results in adding a led_cdev addition and later aanother call to access of led_cdev attribute from Process B can resultin NULL pointer issue.Use mutex led_cdev->led_access to protect access to led->cdev and itsattribute inside brightness_show() and max_brightness_show() and alsoupdate the comment for mutex that it should be used to protect the ledclass device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 3313.874301][ T4013] Mem abort info:[ 3313.874303][ T4013] ESR = 0x0000000096000006[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits[ 3313.874307][ T4013] SET = 0, FnV = 0[ 3313.874309][ T4013] EA = 0, S1PTW = 0[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault[ 3313.874313][ T4013] Data abort info:[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000..[ 3313.874332][ T4013] Dumping ftrace buffer:[ 3313.874334][ T4013] (ftrace buffer empty)....[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60[ 3313.874656][ T4013] sp : ffffffc0b910bbd0....[ 3313.874685][ T4013] Call trace:[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74[ 3313.874690][ T4013] brightness_show+0x20/0x4c[ 3313.874692][ T4013] dev_attr_show+0x38/0x74[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8[ 3313.874711][ T4013] ksys_read+0x78/0xe8[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c[ 3313.874718][ T4013] invoke_syscall+0x58/0x114[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28[ 3313.874727][ T4013] el0_svc+0x38/0x68[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56610 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:kcsan: Turn report_filterlist_lock into a raw_spinlockRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can seesplats like:| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1| preempt_count: 10002, expected: 0| RCU nest depth: 0, expected: 0| no locks held by swapper/1/0.| irq event stamp: 156674| hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240| hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0| softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60| softirqs last disabled at (0): [<0000000000000000>] 0x0| Preemption disabled at:| [] paint_ptr+0x2a/0x90| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014| Call Trace:| | dump_stack_lvl+0x7e/0xc0| dump_stack+0x1d/0x30| __might_resched+0x1a2/0x270| rt_spin_lock+0x68/0x170| kcsan_skip_report_debugfs+0x43/0xe0| print_report+0xb5/0x590| kcsan_report_known_origin+0x1b1/0x1d0| kcsan_setup_watchpoint+0x348/0x650| __tsan_unaligned_write1+0x16d/0x1d0| hrtimer_interrupt+0x3d6/0x430| __sysvec_apic_timer_interrupt+0xe8/0x3a0| sysvec_apic_timer_interrupt+0x97/0xc0| On a detected data race, KCSAN's reporting logic checks if it shouldfilter the report. That list is protected by the report_filterlist_lock*non-raw* spinlock which may sleep on RT kernels.Since KCSAN may report data races in any context, convert it to araw_spinlock.This requires being careful about when to allocate memory for the filterlist itself which can be done via KCSAN's debugfs interface. Concurrentmodification of the filter list via debugfs should be rare: the chosenstrategy is to optimistically pre-allocate memory before the criticalsection and discard if unused.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56637 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Hold module reference while requesting a moduleUser space may unload ip_set.ko while it is itself requesting a set typebackend module, leading to a kernel crash. The race condition may beprovoked by inserting an mdelay() right after the nfnl_unlock() call.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56670 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointerConsidering that in some extreme cases,when u_serial driver is accessed by multiple threads,Thread A is executing the open operation and calling the gs_open,Thread B is executing the disconnect operation and calling thegserial_disconnect function,The port->port_usb pointer will be set to NULL.E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) CrashThis causes thread A to access a null pointer (port->port_usb is null)when calling the gs_free_requests function, causing a crash.If port_usb is NULL, the release request will be skipped as itwill be done by gserial_disconnect.So add a null pointer check to gs_start_io before attemptingto access the value of the pointer port->port_usb.Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56700 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: wl128x: Fix atomicity violation in fmc_send_cmd()Atomicity violation occurs when the fmc_send_cmd() function is executedsimultaneously with the modification of the fmdev->resp_skb value.Consider a scenario where, after passing the validity check within thefunction, a non-null fmdev->resp_skb variable is assigned a null value.This results in an invalid fmdev->resp_skb variable passing the validitycheck. As seen in the later part of the function, skb = fmdev->resp_skb;when the invalid fmdev->resp_skb passes the check, a null pointerdereference error may occur at line 478, evt_hdr = (void *)skb->data;To address this issue, it is recommended to include the validity check offmdev->resp_skb within the locked section of the function. Thismodification ensures that the value of fmdev->resp_skb does not changeduring the validation process, thereby maintaining its validity.This possible bug is found by an experimental static analysis tooldeveloped by our team. This tool analyzes the locking APIsto extract function pairs that can be concurrently executed, and thenanalyzes the instructions in the paired functions to identify possibleconcurrency bugs including data races and atomicity violations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56705 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: Add check for rgby_data memory allocation failureIn ia_css_3a_statistics_allocate(), there is no check on the allocationresult of the rgby_data memory. If rgby_data is not successfullyallocated, it may trigger the assert(host_stats->rgby_data) assertion inia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56725 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56738 Severity: Moderate CVSS3 score: 4.7

Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.

Packages affected:

grub2 > 0-0 (version in image is 2.06-150400.11.63.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2024-56780 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:quota: flush quota_release_work upon quota writebackOne of the paths quota writeback is called from is:freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots()Since we currently don't always flush the quota_release_work queue inthis path, we can end up with the following race: 1. dquot are added to releasing_dquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quota_release_work queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state: ext4_journal_check_start+0x28/0x110 [ext4] (unreliable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0Which is the following line: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);Which ultimately results in generic/390 failing due to dmesgnoise. This was detected on powerpc machine 15 cores.To avoid this, make sure to flush the workqueue duringdquot_writeback_dquots() so we dont have any pending workitems afterfreeze.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21651 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: don't auto enable misc vectorCurrently, there is a time window between misc irq enabledand service task inited. If an interrupte is reported atthis time, it will cause warning like below:[ 16.324639] Call trace:[ 16.324641] __queue_delayed_work+0xb8/0xe0[ 16.324643] mod_delayed_work_on+0x78/0xd0[ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge][ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge][ 16.324666] __handle_irq_event_percpu+0x64/0x1e0[ 16.324667] handle_irq_event+0x80/0x170[ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc[ 16.324671] __handle_domain_irq+0x84/0xfc[ 16.324673] gic_handle_irq+0x88/0x2c0[ 16.324674] el1_irq+0xb8/0x140[ 16.324677] arch_cpu_idle+0x18/0x40[ 16.324679] default_idle_call+0x5c/0x1bc[ 16.324682] cpuidle_idle_call+0x18c/0x1c4[ 16.324684] do_idle+0x174/0x17c[ 16.324685] cpu_startup_entry+0x30/0x6c[ 16.324687] secondary_start_kernel+0x1a4/0x280[ 16.324688] ---[ end trace 6aa0bff672a964aa ]---So don't auto enable misc vector when request irq..

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21664 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: make get_first_thin use rcu-safe list first functionThe documentation in rculist.h explains the absence of list_empty_rcu()and cautions programmers against relying on a list_empty() ->list_first() sequence in RCU safe code. This is because each of thesefunctions performs its own READ_ONCE() of the list head. This can leadto a situation where the list_empty() sees a valid list entry, but thesubsequent list_first() sees a different view of list head state after amodification.In the case of dm-thin, this author had a production box crash from a GPfault in the process_deferred_bios path. This function saw a valid listhead in get_first_thin() but when it subsequently dereferenced that andturned it into a thin_c, it got the inside of the struct pool, since thelist was now empty and referring to itself. The kernel on which thisoccurred printed both a warning about a refcount_t being saturated, anda UBSAN error for an out-of-bounds cpuid access in the queued spinlock,prior to the fault itself. When the resulting kdump was examined, itwas possible to see another thread patiently waiting in thin_dtr'ssynchronize_rcu.The thin_dtr call managed to pull the thin_c out of the active thinslist (and have it be the last entry in the active_thins list) at justthe wrong moment which lead to this crash.Fortunately, the fix here is straight forward. Switch get_first_thin()function to use list_first_or_null_rcu() which performs just a singleREAD_ONCE() and returns NULL if the list is already empty.This was run against the devicemapper test suite's thin-provisioningsuites for delete and suspend and no regressions were observed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21669 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: discard packets if the transport changesIf the socket has been de-assigned or assigned to another transport,we must discard any packets received because they are not expectedand would cause issues when we access vsk->transport.A possible scenario is described by Hyunwoo Kim in the attached link,where after a first connect() interrupted by a signal, and a secondconnect() failed, we can find `vsk->transport` at NULL, leading to aNULL pointer dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21682 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: always recalculate features after XDP clearing, fix null-derefRecalculate features when XDP is detached.Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: onThe fact that HW-GRO doesn't get re-enabled automatically is justa minor annoyance. The real issue is that the features will randomlycome back during another reconfiguration which just happens to invokenetdev_update_features(). The driver doesn't handle reconfiguringtwo things at a time very robustly.Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") we only reconfigure the RSS hash tableif the "effective" number of Rx rings has changed. If HW-GRO isenabled "effective" number of rings is 2x what user sees.So if we are in the bad state, with HW-GRO re-enablement "pending"after XDP off, and we lower the rings by / 2 - the HW-GRO ringsdoing 2x and the ethtool -L doing / 2 may cancel each other out,and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings &&condition in __bnxt_reserve_rings() will be false.The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0As we try to access a freed ring.The issue is present since XDP support was added, really, butprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") it wasn't causing major issues.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21684 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: xilinx: Convert gpio_lock to raw spinlockirq_chip functions may be called in raw spinlock context. Therefore, wemust also use a raw spinlock for our own internal locking.This fixes the following lockdep splat:[ 5.349336] =============================[ 5.353349] [ BUG: Invalid wait context ][ 5.357361] 6.13.0-rc5+ #69 Tainted: G W[ 5.363031] -----------------------------[ 5.367045] kworker/u17:1/44 is trying to lock:[ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.380079] other info that might help us debug this:[ 5.385138] context-{5:5}[ 5.387762] 5 locks held by kworker/u17:1/44:[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)[ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)[ 5.436472] stack backtrace:[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69[ 5.448690] Tainted: [W]=WARN[ 5.451656] Hardware name: xlnx,zynqmp (DT)[ 5.455845] Workqueue: events_unbound deferred_probe_work_func[ 5.461699] Call trace:[ 5.464147] show_stack+0x18/0x24 C[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)[ 5.471501] dump_stack (lib/dump_stack.c:130)[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)[ 5.497645] irq_startup (kernel/irq/chip.c:270)[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21943 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: aggregator: protect driver attr handlers against module unloadBoth new_device_store and delete_device_store touch module globalresources (e.g. gpio_aggregator_lock). To prevent race conditions withmodule unload, a reference needs to be held.Add try_module_get() in these handlers.For new_device_store, this eliminates what appears to be the most dangerousscenario: if an id is allocated from gpio_aggregator_idr butplatform_device_register has not yet been called or completed, a concurrentmodule unload could fail to unregister/delete the device, leaving behind adangling platform device/GPIO forwarder. This can result in various issues.The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22027 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: streamzap: fix race between device disconnection and urb callbackSyzkaller has reported a general protection fault at functionir_raw_event_store_with_filter(). This crash is caused by a NULL pointerdereference of dev->raw pointer, even though it is checked for NULL inthe same function, which means there is a race condition. It occurs dueto the incorrect order of actions in the streamzap_disconnect() function:rc_unregister_device() is called before usb_kill_urb(). The dev->rawpointer is freed and set to NULL in rc_unregister_device(), and onlyafter that usb_kill_urb() waits for in-progress requests to finish.If rc_unregister_device() is called while streamzap_callback() handler isnot finished, this can lead to accessing freed resources. Thusrc_unregister_device() should be called after usb_kill_urb().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22030 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holdingthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock(through crypto_exit_scomp_ops_async()).On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (throughcrypto_scomp_init_tfm()), and then allocates memory. If the allocationresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.The above dependencies can cause an ABBA deadlock. For example in thefollowing scenario:(1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1)(2) Task A is descheduled(3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock(4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCKSince there is no requirement to call crypto_free_acomp() with the per-CPUacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex isunlocked. Also move the acomp_request_free() and kfree() calls forconsistency and to avoid any potential sublte locking dependencies in thefuture.With this, only setting acomp_ctx fields to NULL occurs with the mutexheld. This is similar to how zswap_cpu_comp_prepare() only initializesacomp_ctx fields with the mutex held, after performing all allocationsbefore holding the mutex.Opportunistically, move the NULL check on acomp_ctx so that it takes placebefore the mutex dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22065 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix adapter NULL pointer dereference on rebootWith SRIOV enabled, idpf ends up calling into idpf_remove() twice.First via idpf_shutdown() and then again when idpf_remove() calls intosriov_disable(), because the VF devices use the idpf driver, hence thesame remove routine. When that happens, it is possible for the adapterto be NULL from the first call to idpf_remove(), leading to a NULLpointer dereference.echo 1 > /sys/class/net//device/sriov_numvfsrebootBUG: kernel NULL pointer dereference, address: 0000000000000020...RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]...? idpf_remove+0x22/0x1f0 [idpf]? idpf_remove+0x1e4/0x1f0 [idpf]pci_device_remove+0x3f/0xb0device_release_driver_internal+0x19f/0x200pci_stop_bus_device+0x6d/0x90pci_stop_and_remove_bus_device+0x12/0x20pci_iov_remove_virtfn+0xbe/0x120sriov_disable+0x34/0xe0idpf_sriov_configure+0x58/0x140 [idpf]idpf_remove+0x1b9/0x1f0 [idpf]idpf_shutdown+0x12/0x30 [idpf]pci_device_shutdown+0x35/0x60device_shutdown+0x156/0x200...Replace the direct idpf_remove() call in idpf_shutdown() withidpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which performthe bulk of the cleanup, such as stopping the init task, freeing IRQs,destroying the vports and freeing the mailbox. This avoids the calls tosriov_disable() in addition to a small netdev cleanup, and destroyingworkqueues, which don't seem to be required on shutdown.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37841 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:pm: cpupower: bench: Prevent NULL dereference on malloc failureIf malloc returns NULL due to low memory, 'config' pointer can be NULL.Add a check to prevent NULL dereference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37856 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: harden block_group::bg_list against list_del() racesAs far as I can tell, these calls of list_del_init() on bg_list cannotrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),as they are in transaction error paths and situations where the blockgroup is readonly.However, if there is any chance at all of racing with mark_bg_unused(),or a different future user of bg_list, better to be safe than sorry.Otherwise we risk the following interleaving (bg_list refcount in parens)T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1)list_del_init(&bg->bg_list); (1) list_move_tail (1)btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1)Ultimately, this results in a broken ref count that hits zero one derefearly and the real final deref underflows the refcount, resulting in a WARNING.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37892 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: inftlcore: Add error check for inftl_read_oob()In INFTL_findwriteunit(), the return value of inftl_read_oob()need to be checked. A proper implementation can befound in INFTL_deleteblock(). The status will be set asSECTOR_IGNORE to break from the while-loop correctlyif the inftl_read_oob() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37928 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm-bufio: don't schedule in atomic contextA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP andtry_verify_in_tasklet are enabled.[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4[ 129.444740][ T934] preempt_count: 201, expected: 0[ 129.444756][ T934] RCU nest depth: 0, expected: 0[ 129.444781][ T934] Preemption disabled at:[ 129.444789][ T934] [] shrink_work+0x21c/0x248[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16![ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug][ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c[ 129.447451][ T934] sp : ffffffc0843dbc90[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000[ 129.447647][ T934] Call trace:[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6][ 129.447681][ T934] __might_resched+0x190/0x1a8[ 129.447694][ T934] shrink_work+0x180/0x248[ 129.447706][ T934] process_one_work+0x260/0x624[ 129.447718][ T934] worker_thread+0x28c/0x454[ 129.447729][ T934] kthread+0x118/0x158[ 129.447742][ T934] ret_from_fork+0x10/0x20[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---dm_bufio_lock will call spin_lock_bh when try_verify_in_taskletis enabled, and __scan will be called in atomic context.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37942 Severity: Moderate CVSS3 score: 4.7

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37951 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Add job to pending list if the reset was skippedWhen a CL/CSD job times out, we check if the GPU has made any progresssince the last timeout. If so, instead of resetting the hardware, we skipthe reset and let the timer get rearmed. This gives long-running jobs achance to complete.However, when `timedout_job()` is called, the job in question is removedfrom the pending list, which means it won't be automatically freed through`free_job()`. Consequently, when we skip the reset and keep the jobrunning, the job won't be freed when it finally completes.This situation leads to a memory leak, as exposed in [1] and [2].Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler whenGPU is still active"), this patch ensures the job is put back on thepending list when extending the timeout.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37983 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:qibfs: fix _another_ leakfailure to allocate inode => leaked dentry...this one had been there since the initial merge; to be fair,if we are that far OOM, the odds of failing at that particularallocation are low...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38102 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notifyDuring our test, it is found that a warning can be trigger in try_grab_folioas follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---Digging into the source, context->notify_page may init by get_user_pages_fastand can be seen in vmci_ctx_unset_notify which will try to put_page. Howeverget_user_pages_fast is not finished here and lead to followingtry_grab_folio warning. The race condition is shown as follow:cpu0 cpu1vmci_host_do_set_notifyvmci_host_setup_notifyget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);lockless_pages_from_mmgup_pgd_rangegup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed__gup_longterm_locked__get_user_pagesfollow_trans_huge_pmdtry_grab_folio // warn hereTo slove this, use local variable page to make notify_page can be seenafter finish get_user_pages_fast.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38105 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Kill timer properly at removalThe USB-audio MIDI code initializes the timer, but in a rare case, thedriver might be freed without the disconnect call. This leaves thetimer in an active state while the assigned object is released viasnd_usbmidi_free(), which ends up with a kernel warning when the debugconfiguration is enabled, as spotted by fuzzer.For avoiding the problem, put timer_shutdown_sync() atsnd_usbmidi_free(), so that the timer can be killed properly.While we're at it, replace the existing timer_delete_sync() at thedisconnect callback with timer_shutdown_sync(), too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38108 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: red: fix a race in __red_change()Gerrard Tai reported a race condition in RED, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38112 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix TOCTOU issue in sk_is_readable()sk->sk_prot->sock_is_readable is a valid function pointer when sk residesin a sockmap. After the last sk_psock_put() (which usually happens whensocket is removed from sockmap), sk->sk_prot gets restored andsk->sk_prot->sock_is_readable becomes NULL.This makes sk_is_readable() racy, if the value of sk->sk_prot is reloadedafter the initial check. Which in turn may lead to a null pointerdereference.Ensure the function pointer does not turn NULL after the check.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38125 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring ESTIf the ptp_rate recorded earlier in the driver happens to be 0, thisbogus value will propagate up to EST configuration, where it willtrigger a division by 0.Prevent this division by 0 by adding the corresponding check and errorcode.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38126 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring timestampingThe stmmac platform drivers that do not open-code the clk_ptp_rate valueafter having retrieved the default one from the device-tree can end upwith 0 in clk_ptp_rate (as clk_get_rate can return 0). It willeventually propagate up to PTP initialization when bringing up theinterface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)Prevent this division by 0 by adding an explicit check and error logabout the actual issue. While at it, remove the same check fromstmmac_ptp_register, which then becomes duplicate

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38203 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix null-ptr-deref in jfs_ioc_trim[ Syzkaller Report ]Oops: general protection fault, probably for non-canonical address0xdffffc0000000087: 0000 [#1KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted6.13.0-rc6-gfbfd64d25c7a-dirty #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Sched_ext: serialise (enabled+all), task: runnable_at=-30msRIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:? __die_body+0x61/0xb0? die_addr+0xb1/0xe0? exc_general_protection+0x333/0x510? asm_exc_general_protection+0x26/0x30? jfs_ioc_trim+0x34b/0x8f0jfs_ioctl+0x3c8/0x4f0? __pfx_jfs_ioctl+0x10/0x10? __pfx_jfs_ioctl+0x10/0x10__se_sys_ioctl+0x269/0x350? __pfx___se_sys_ioctl+0x10/0x10? do_syscall_64+0xfb/0x210do_syscall_64+0xee/0x210? syscall_exit_to_user_mode+0x1e0/0x330entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe51f4903adCode: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 4889 f7 48 89 d6 48 89 ca 4dRSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903adRDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Kernel panic - not syncing: Fatal exception[ Analysis ]We believe that we have found a concurrency bug in the `fs/jfs` modulethat results in a null pointer dereference. There is a closely relatedissue which has been fixed:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... but, unfortunately, the accepted patch appears to still besusceptible to a null pointer dereference under some interleavings.To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is setto NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. Thisbug manifests quite rarely under normal circumstances, but istriggereable from a syz-program.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38231 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Initialize ssc before laundromat_work to prevent NULL dereferenceIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc throughnfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized,this can cause NULL pointer dereference.Normally the delayed start of laundromat_work allows sufficient time fornfsd_ssc initialization to complete. However, when the kernel waits toolong for userspace responses (e.g. in nfs4_state_start_net ->nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done ->cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), thedelayed work may start before nfsd_ssc initialization finishes.Fix this by moving nfsd_ssc initialization before starting laundromat_work.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38234 Severity: Moderate CVSS3 score: 4.7

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38244 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.16.0-rc3-build2+ #1301 Tainted: G S W------------------------------------------------------cifsd/6055 is trying to acquire lock:ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30other info that might help us debug this:Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK ***3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38245 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().syzbot reported a warning below during atm_dev_register(). [0]Before creating a new device and procfs/sysfs for it, atm_dev_register()looks up a duplicated device by __atm_dev_lookup(). These operations aredone under atm_dev_mutex.However, when removing a device in atm_dev_deregister(), it releases themutex just after removing the device from the list that __atm_dev_lookup()iterates over.So, there will be a small race window where the device does not exist onthe device list but procfs/sysfs are still not removed, triggering thesplat.Let's hold the mutex until procfs/sysfs are removed inatm_dev_deregister().[0]:proc_dir_entry 'atm/atmtcp:0' already registeredWARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377Modules linked in:CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f38b3b74459Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0acR13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38250 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix use-after-free in vhci_flush()syzbot reported use-after-free in vhci_flush() without repro. [0]From the splat, a thread close()d a vhci file descriptor whileits device was being used by iotcl() on another thread.Once the last fd refcnt is released, vhci_release() callshci_unregister_dev(), hci_free_dev(), and kfree() for structvhci_data, which is set to hci_dev->dev->driver_data.The problem is that there is no synchronisation after unlinkinghdev from hci_dev_list in hci_unregister_dev(). There might beanother thread still accessing the hdev which was fetched beforethe unlink operation.We can use SRCU for such synchronisation.Let's run hci_dev_reset() under SRCU and wait for its completionin hci_unregister_dev().Another option would be to restore hci_dev->destruct(), which wasremoved in commit 587ae086f6e4 ("Bluetooth: Remove unusedhci-destruct cb"). However, this would not be a good solution, aswe should not run hci_unregister_dev() while there are in-flightioctl() requests, which could lead to another data-race KCSAN splat.Note that other drivers seem to have the same problem, for exmaple,virtbt_remove().[0]:BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fcf5b98e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38293 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix node corruption in ar->arvifs listIn current WLAN recovery code flow, ath11k_core_halt() onlyreinitializes the "arvifs" list head. This will cause thelist node immediately following the list head to become aninvalid list node. Because the prev of that node still pointsto the list head "arvifs", but the next of the list head "arvifs"no longer points to that list node.When a WLAN recovery occurs during the execution of a vifremoval, and it happens before the spin_lock_bh(&ar->data_lock)in ath11k_mac_op_remove_interface(), list_del() will detect thepreviously mentioned situation, thereby triggering a kernel panic.The fix is to remove and reinitialize all vif list nodes from thelist head "arvifs" during WLAN halt. The reinitialization is to makethe list nodes valid, ensuring that the list_del() inath11k_mac_op_remove_interface() can execute normally.Call trace:__list_del_entry_valid_or_report+0xb8/0xd0ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]drv_remove_interface+0x48/0x194 [mac80211]ieee80211_do_stop+0x6e0/0x844 [mac80211]ieee80211_stop+0x44/0x17c [mac80211]__dev_close_many+0xac/0x150__dev_change_flags+0x194/0x234dev_change_flags+0x24/0x6cdevinet_ioctl+0x3a0/0x670inet_ioctl+0x200/0x248sock_do_ioctl+0x60/0x118sock_ioctl+0x274/0x35c__arm64_sys_ioctl+0xac/0xf0invoke_syscall+0x48/0x114...Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38373 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:IB/mlx5: Fix potential deadlock in MR deregistrationThe issue arises when kzalloc() is invoked while holding umem_mutex orany other lock acquired under umem_mutex. This is problematic becausekzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invokemmu_notifier_invalidate_range_start(). This function can lead tomlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,resulting in a deadlock.The problematic flow: CPU0 | CPU1---------------------------------------|------------------------------------------------mlx5_ib_dereg_mr() | -> revoke_mr() | -> mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | -> mutex_lock(&dev->cache.rb_lock) | -> mlx5r_cache_create_ent_locked() | -> kzalloc(GFP_KERNEL) | -> fs_reclaim() | -> mmu_notifier_invalidate_range_start() | -> mlx5_ib_invalidate_range() | -> mutex_lock(&umem_odp->umem_mutex) -> cache_ent_find_and_store() | -> mutex_lock(&dev->cache.rb_lock) |Additionally, when kzalloc() is called from withincache_ent_find_and_store(), we encounter the same deadlock due tore-acquisition of umem_mutex.Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()and before acquiring rb_lock. This ensures that we don't holdumem_mutex while performing memory allocations that could triggerthe reclaim path.This change prevents the deadlock by ensuring proper lock ordering andavoiding holding locks during memory allocation operations that couldtrigger the reclaim path.The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38383 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38387 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insertThe obj_event may be loaded immediately after inserted, then if thelist_head is not initialized then we may get a poisonous pointer. Thisfixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38393 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAINWe found a few different systems hung up in writeback waiting on the samepage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit inpnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding countwas zero.It seems most likely that this is another race between the waiter and wakersimilar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").Fix it up by applying the advised barrier.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38428 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Input: ims-pcu - check record size in ims_pcu_flash_firmware()The "len" variable comes from the firmware and we generally dotrust firmware, but it's always better to double check. If the "len"is too large it could result in memory corruption when we do"memcpy(fragment->data, rec->data, len);"

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38436 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38460 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix potential null-ptr-deref in to_atmarpd().atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clipcauses unregister hang").However, it is not enough because to_atmarpd() is called without RTNL,especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable.Also, there is no RTNL dependency around atmarpd.Let's use a private mutex and RCU to protect access to atmarpd into_atmarpd().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38461 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_* TOCTOUTransport assignment may race with module unload. Protect new_transportfrom becoming a stale pointer.This also takes care of an insecure call in vsock_use_local_transport();add a lockdep assert.BUG: unable to handle page fault for address: fffffbfff8056000Oops: Oops: 0000 [#1] SMP KASANRIP: 0010:vsock_assign_transport+0x366/0x600Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38467 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: exynos7_drm_decon: add vblank check in IRQ handlingIf there's support for another console device (such as a TTY serial),the kernel occasionally panics during boot. The panic message and arelevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...]Otherwise, the panics don't happen. This indicates that it's some sortof race condition.Add a check to validate if the drm device can handle vblanks beforecalling drm_crtc_handle_vblank() to avoid this.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38473 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]l2cap_sock_resume_cb() has a similar problem that was fixed by commit1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executedunder l2cap_sock_resume_cb(), we can avoid the issue simply by checkingif chan->data is NULL.Let's not access to the killed socket in l2cap_sock_resume_cb().[0]:BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Workqueue: hci0 hci_rx_workCall trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38513 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). Forexample, the following is possible: T0 T1zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; itype == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULLSince there is a small gap between checking skb queue length and skb beingunconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.In order to avoid potential NULL pointer dereference due to situations likeabove, check if skb is not NULL before passing it to zd_mac_tx_status().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38515 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Increment job count before swapping tail spsc queueA small race exists between spsc_queue_push and the run-job worker, inwhich spsc_queue_push may return not-first while the run-job worker hasalready idled due to the job count being zero. If this race occurs, jobscheduling stops, leading to hangs while waiting on the job's DMAfences.Seal this race by incrementing the job count before appending to theSPSC queue.This race was observed on a drm-tip 6.16-rc1 build with the Xe driver inan SVM test case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38520 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Don't call mmput from MMU notifier callbackIf the process is exiting, the mmput inside mmu notifier callback fromcompactd or fork or numa balancing could release the last referenceof mm struct to call exit_mmap and free_pgtable, this triggers deadlockwith below backtrace.The deadlock will leak kfd process as mmu notifier release is not calledand cause VRAM leaking.The fix is to take mm reference mmget_non_zero when adding prange to thedeferred list to pair with mmput in deferred list work.If prange split and add into pchild list, the pchild work_item.mm is notused, so remove the mm parameter from svm_range_unmap_split andsvm_range_add_child.The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu](cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38538 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: nbpfaxi: Fix memory corruption in probe()The nbpf->chan[] array is allocated earlier in the nbpf_probe() functionand it has "num_channels" elements. These three loops iterate oneelement farther than they should and corrupt memory.The changes to the second loop are more involved. In this case, we'recopying data from the irqbuf[] array into the nbpf->chan[] array. Ifthe data in irqbuf[i] is the error IRQ then we skip it, so the iteratorsare not in sync. I added a check to ensure that we don't go beyond theend of the irqbuf[] array. I'm pretty sure this can't happen, but itseemed harmless to add a check.On the other hand, after the loop has ended there is a check to ensurethat the "chan" iterator is where we expect it to be. In the originalcode we went one element beyond the end of the array so the iteratorwasn't in the correct place and it would always return -EINVAL. However,now it will always be in the correct place. I deleted the check sincewe know the result.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38544 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix bug due to prealloc collisionWhen userspace is using AF_RXRPC to provide a server, it has to preallocateincoming calls and assign to them call IDs that will be used to threadrelated recvmsg() and sendmsg() together. The preallocated call IDs willautomatically be attached to calls as they come in until the pool is empty.To the kernel, the call IDs are just arbitrary numbers, but userspace canuse the call ID to hold a pointer to prepared structs. In any case, theuser isn't permitted to create two calls with the same call ID (call IDsbecome available again when the call ends) and EBADSLT should result fromsendmsg() if an attempt is made to preallocate a call with an in-use callID.However, the cleanup in the error handling will trigger both assertions inrxrpc_cleanup_call() because the call isn't marked complete and isn'tmarked as having been released.Fix this by setting the call state in rxrpc_service_prealloc_one() and thenmarking it as being released before calling the cleanup function.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38546 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix memory leak of struct clip_vcc.ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it tovcc->user_back.The code assumes that vcc_destroy_socket() passes NULL skbto vcc->push() when the socket is close()d, and then clip_push()frees clip_vcc.However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() inatm_init_atmarp(), resulting in memory leak.Let's serialise two ioctl() by lock_sock() and check vcc->push()in atm_init_atmarp() to prevent memleak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38576 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: Make EEH driver device hotplug safeMultiple race conditions existed between the PCIe hotplug driver and theEEH driver, leading to a variety of kernel oopses of the same generalnature:A second class of oops is also seen when the underlying bus disappearsduring device recovery.Refactor the EEH module to be PCI rescan and remove safe. Also cleanup a few minor formatting / readability issues.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38595 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:xen: fix UAF in dmabuf_exp_from_pages()[dma_buf_fd() fixes; no preferences regarding the tree it goes through -up to xen folks]As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().gntdev dmabuf_exp_from_pages() calls it and then proceeds to access theobjects destroyed on close - starting with gntdev_dmabuf itself.Fix that by doing reserving descriptor before anything else and dofd_install() only when everything had been set up.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38637 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: skbprio: Remove overly strict queue assertionsIn the current implementation, skbprio enqueue/dequeue contains an assertionthat fails under certain conditions when SKBPRIO is used as a child qdisc underTBF with specific parameters. The failure occurs because TBF sometimes peeks atpackets in the child qdisc without actually dequeuing them when tokens areunavailable.This peek operation creates a discrepancy between the parent and child qdiscqueue length counters. When TBF later receives a high-priority packet,SKBPRIO's queue length may show a different value than what's reflected in itsinternal priority queue tracking, triggering the assertion.The fix removes this overly strict assertions in SKBPRIO, they are notnecessary at all.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38650 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: remove mutex_lock check in hfsplus_free_extentsSyzbot reported an issue in hfsplus filesystem:------------[ cut here ]------------WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0Call Trace:hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56cont_expand_zero fs/buffer.c:2383 [inline]cont_write_begin+0x2cf/0x860 fs/buffer.c:2446hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263notify_change+0xe38/0x10f0 fs/attr.c:420do_truncate+0x1fb/0x2e0 fs/open.c:65do_sys_ftruncate+0x2eb/0x380 fs/open.c:193do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdTo avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlockon file truncation") unlock extree before hfsplus_free_extents(),and add check wheather extree is locked in hfsplus_free_extents().However, when operations such as hfsplus_file_release,hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executedconcurrently in different files, it is very likely to trigger theWARN_ON, which will lead syzbot and xfstest to consider it as anabnormality.The comment above this warning also describes one of the easytriggering situations, which can easily trigger and causexfstest&syzbot to report errors.[task A] [task B]->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!Several threads could try to lock the shared extents tree.And warning can be triggered in one thread when another threadhas locked the tree. This is the wrong behavior of the code andwe need to remove the warning.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8114 Severity: Moderate CVSS3 score: 4.7

Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.12.1).

CVE-2024-42226 Severity: Moderate CVSS3 score: 4.6

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21704 Severity: Moderate CVSS3 score: 4.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can'tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm->nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1("cdc-acm: reassemble fragmented notifications").A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device's vendor/product IDs andits other interfaces.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38348 Severity: Moderate CVSS3 score: 4.6

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()Robert Morris reported:|If a malicious USB device pretends to be an Intersil p54 wifi|interface and generates an eeprom_readback message with a large|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the|message beyond the end of priv->eeprom.||static void p54_rx_eeprom_readback(struct p54_common *priv,| struct sk_buff *skb)|{| struct p54_hdr *hdr = (struct p54_hdr *) skb->data;| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data;|| if (priv->fw_var >= 0x509) {| memcpy(priv->eeprom, eeprom->v2.data,| le16_to_cpu(eeprom->v2.len));| } else {| memcpy(priv->eeprom, eeprom->v1.data,| le16_to_cpu(eeprom->v1.len));| }| [...]The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom().The device is supposed to provide the same length back to the driver.But yes, it's possible (like shown in the report) to alter the valueto something that causes a crash/panic due to overrun.This patch addresses the issue by adding the size to the common devicecontext, so p54_rx_eeprom_readback no longer relies on possibly tamperedvalues... That said, it also checks if the "firmware" altered the valueand no longer copies them.The one, small saving grace is: Before the driver tries to read the eeprom,it needs to upload >a< firmware. the vendor firmware has a proprietarylicense and as a reason, it is not present on most distributions bydefault.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49814 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: close race conditions on sk_receive_queuesk->sk_receive_queue is protected by skb queue lock, but for KCMsockets its RX path takes mux->rx_lock to protect more than justskb queue. However, kcm_recvmsg() still only grabs the skb queuelock, so race conditions still exist.We can teach kcm_recvmsg() to grab mux->rx_lock too but this wouldintroduce a potential performance regression as struct kcm_mux canbe shared by multiple KCM sockets.So we have to enforce skb queue lock in requeue_rx_msgs() and handleskb peek case carefully in kcm_wait_data(). Fortunately,skb_recv_datagram() already handles it nicely and is widely used byother sockets, we can just switch to skb_recv_datagram() aftergetting rid of the unnecessary sock lock in kcm_recvmsg() andkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,so it is safe to get rid of this check too.I ran the original syzbot reproducer for 30 min without seeing anyissue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52503 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix use-after-free vulnerability in amdtee_close_sessionThere is a potential race condition in amdtee_close_session that maycause use-after-free in amdtee_open_session. For instance, if a sessionhas refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session);the reference count will get decremented, and the next step would be tocall destroy_session(). However, if in another thread,amdtee_open_session() is called before destroy_session() has completedexecution, alloc_session() may return 'sess' that will be freed uplater in destroy_session() leading to use-after-free inamdtee_open_session.To fix this issue, treat decrement of sess->refcount and removal of'sess' from session list in destroy_session() as a critical section, sothat it is executed atomically.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43790 Severity: Moderate CVSS3 score: 4.5

Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2024-43802 Severity: Moderate CVSS3 score: 4.5

Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-0840 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1182 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-37920 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race condition in AF_XDP generic RX pathMove rx_lock from xsk_socket to xsk_buff_pool.Fix synchronization for shared umem mode ingeneric RX path where multiple sockets sharesingle xsk_buff_pool.RX queue is exclusive to xsk_socket, while FILLqueue can be shared between multiple sockets.This could result in race condition where twoCPU cores access RX path of two different socketssharing the same umem.Protect both queues by acquiring spinlock in sharedxsk_buff_pool.Lock contention may be minimized in the future by someper-thread FQ buffering.It's safe and necessary to move spin_lock_bh(rx_lock)after xsk_rcv_check():* xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers.* xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-3521 Severity: Moderate CVSS3 score: 4.4

Description: There is a flaw in RPM's signature functionality. OpenPGP subkeys are associated with a primary key via a "binding signature." RPM does not check the binding signature of subkeys prior to importing them. If an attacker is able to add or socially engineer another party to add a malicious subkey to a legitimate public key, RPM could wrongly trust a malicious signature. The greatest impact of this flaw is to data integrity. To exploit this flaw, an attacker must either compromise an RPM repository or convince an administrator to install an untrusted RPM or public key. It is strongly recommended to only use RPMs and public keys from trusted sources.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
rpm-build > 0-0 (version in image is 4.14.3-150400.59.16.1).

CVE-2021-47572 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: nexthop: fix null pointer dereference when IPv6 is not enabledWhen we try to add an IPv6 nexthop and IPv6 is not enabled(!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error pathof nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bughas been present since the beginning of IPv6 nexthop gateway support.Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tellsus that only fib6_nh_init has a dummy stub because fib6_nh_release shouldnot be called if fib6_nh_init returns an error, but the commit below addeda call to ipv6_stub->fib6_nh_release in its error path. To fix it returnthe dummy stub's -EAFNOSUPPORT error directly without callingipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.[1] Output is a bit truncated, but it clearly shows the error. BUG: kernel NULL pointer dereference, address: 000000000000000000 #PF: supervisor instruction fetch in kernel modede #PF: error_code(0x0010) - not-present pagege PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860 RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000 R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840 FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0 Call Trace: nh_create_ipv6+0xed/0x10c rtm_new_nexthop+0x6d7/0x13f3 ? check_preemption_disabled+0x3d/0xf2 ? lock_is_held_type+0xbe/0xfd rtnetlink_rcv_msg+0x23f/0x26a ? check_preemption_disabled+0x3d/0xf2 ? rtnl_calcit.isra.0+0x147/0x147 netlink_rcv_skb+0x61/0xb2 netlink_unicast+0x100/0x187 netlink_sendmsg+0x37f/0x3a0 ? netlink_unicast+0x187/0x187 sock_sendmsg_nosec+0x67/0x9b ____sys_sendmsg+0x19d/0x1f9 ? copy_msghdr_from_user+0x4c/0x5e ? rcu_read_lock_any_held+0x2a/0x78 ___sys_sendmsg+0x6c/0x8c ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? lockdep_hardirqs_on+0xd9/0x102 ? sockfd_lookup_light+0x69/0x99 __sys_sendmsg+0x50/0x6e do_syscall_64+0xcb/0xf2 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f98dea28914 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53 RSP: 002b:00007fff859f5e68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e2e RAX: ffffffffffffffda RBX: 00000000619cb810 RCX: 00007f98dea28914 RDX: 0000000000000000 RSI: 00007fff859f5ed0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008 R10: fffffffffffffce6 R11: 0000000000000246 R12: 0000000000000001 R13: 000055c0097ae520 R14: 000055c0097957fd R15: 00007fff859f63a0 Modules linked in: bridge stp llc bonding virtio_net

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48850 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net-sysfs: add check for netdevice being present to speed_showWhen bringing down the netdevice or system shutdown, a panic can betriggered while accessing the sysfs path because the device is alreadyremoved. [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)To prevent this scenario, we also make sure that the netdevice is present.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48957 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()The cmd_buff needs to be freed when error happened indpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49048 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix panic when forwarding a pkt with no in6 devkongweibin reported a kernel panic in ip6_forward() when input interfacehas no in6 dev associated.The following tc commands were used to reproduce this panic:tc qdisc del dev vxlan100 roottc qdisc add dev vxlan100 root netem corrupt 5%

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49138 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Ignore multiple conn complete eventsWhen one of the three connection complete events is received multipletimes for the same handle, the device is registered multiple times whichleads to memory corruptions. Therefore, consequent events for a singleconnection are ignored.The conn->state can hold different values, therefore HCI_CONN_HANDLE_UNSETis introduced to identify new connections. To make sure the events do notcontain this or another invalid handle HCI_CONN_HANDLE_MAX and checksare introduced.Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49932 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspaceCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes/dev/kvm to userspace and thus allows userspace to create VMs (and callother ioctls). E.g. KVM will encounter a NULL pointer when attempting toadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able tocreate a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-40546 Severity: Moderate CVSS3 score: 4.4

Description: A flaw was found in Shim when an error happened while creating a new ESL variable. If Shim fails to create the new variable, it tries to print an error message to the user; however, the number of parameters used by the logging function doesn't match the format string used by it, leading to a crash under certain circumstances.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2023-40549 Severity: Moderate CVSS3 score: 4.4

Description: An out-of-bounds read flaw was found in Shim due to the lack of proper boundary verification during the load of a PE binary. This flaw allows an attacker to load a crafted PE binary, triggering the issue and crashing Shim, resulting in a denial of service.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2023-40551 Severity: Moderate CVSS3 score: 4.4

Description: A flaw was found in the MZ binary format in Shim. An out-of-bounds read may occur, leading to a crash or possible exposure of sensitive data during the system's boot phase.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2023-46838 Severity: Moderate CVSS3 score: 4.4

Description: Transmit requests in Xen's virtual network protocol can consist ofmultiple parts. While not really useful, except for the initial partany of them may be of zero length, i.e. carry no data at all. Besides acertain initial portion of the to be transferred data, these parts aredirectly translated into what Linux calls SKB fragments. Such convertedrequest parts can, when for a particular SKB they are all of lengthzero, lead to a de-reference of NULL in core networking code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52595 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rt2x00: restart beacon queue when hardware resetWhen a hardware reset is triggered, all registers are reset, so allqueues are forced to stop in hardware interface. However, mac80211will not automatically stop the queue. If we don't manually stop thebeacon queue, the queue will be deadlocked and unable to start again.This patch fixes the issue where Apple devices cannot connect to theAP after calling ieee80211_restart_hw().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52614 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix buffer overflow in trans_stat_showFix buffer overflow in trans_stat_show().Convert simple snprintf to the more secure scnprintf with size ofPAGE_SIZE.Add condition checking if we are exceeding PAGE_SIZE and exit early fromloop. Also add at the end a warning that we exceeded PAGE_SIZE and thatstats is disabled.Return -EFBIG in the case where we don't have enough space to write thefull transition table.Also document in the ABI that this function can return -EFBIG error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52618 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:block/rnbd-srv: Check for unlikely string overflowSince "dev_search_path" can technically be as large as PATH_MAX,there was a risk of truncation when copying it and a second stringinto "full_path" since it was also PATH_MAX sized. The W=1 builds werereporting this warning:drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~To fix this, unconditionally check for truncation (as was already donefor the case where "%SESSNAME%" was present).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52622 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid online resizing failures due to oversized flex bgWhen we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16Gthe following WARN_ON is triggered:==================================================================WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550Modules linked in: sg(E)CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314RIP: 0010:__alloc_pages+0x411/0x550Call Trace: __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90==================================================================This is because flexbg_size is too large and the size of the new_group_dataarray to be allocated exceeds MAX_ORDER. Currently, the minimum value ofMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the correspondingmaximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ~ 21845And the value that is down-aligned to the power of 2 is 16384. Therefore,this value is defined as MAX_RESIZE_BG, and the number of groups addedeach time does not exceed this value during resizing, and is added multipletimes to complete the online resizing. The difference is that the metadatain a flex_bg may be more dispersed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52884 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Input: cyapa - add missing input core locking to suspend/resume functionsGrab input->mutex during suspend/resume functions like it is done inother input drivers. This fixes the following warning during systemsuspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:------------[ cut here ]------------WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6cModules linked in: ...CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109Hardware name: Samsung Exynos (Flattened Device Tree)Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28Exception stack(0xf1625fb0 to 0xf1625ff8)...---[ end trace 0000000000000000 ]---...------------[ cut here ]------------WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6cModules linked in: ...CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109Hardware name: Samsung Exynos (Flattened Device Tree)Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28Exception stack(0xf1625fb0 to 0xf1625ff8)...---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7042 Severity: Moderate CVSS3 score: 4.4

Description: A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7192 Severity: Moderate CVSS3 score: 4.4

Description: A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0841 Severity: Moderate CVSS3 score: 4.4

Description: A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-23851 Severity: Moderate CVSS3 score: 4.4

Description: copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-25629 Severity: Moderate CVSS3 score: 4.4

Description: c-ares is a C library for asynchronous DNS requests. `ares__read_line()` is used to parse local configuration files such as `/etc/resolv.conf`, `/etc/nsswitch.conf`, the `HOSTALIASES` file, and if using a c-ares version prior to 1.27.0, the `/etc/hosts` file. If any of these configuration files has an embedded `NULL` character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libcares2 > 0-0 (version in image is 1.19.1-150000.3.26.1).

CVE-2024-26810 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Lock external INTx masking opsMask operations through config space changes to DisINTx may race INTxconfiguration changes via ioctl. Create wrappers that add locking forpaths outside of the core interrupt code.In particular, irq_type is updated holding igate, therefore testingis_intx() requires holding igate. For example clearing DisINTx fromconfig space can otherwise race changes of the interrupt configuration.This aligns interfaces which may trigger the INTx eventfd into twocamps, one side serialized by igate and the other only enabled whileINTx is configured. A subsequent patch introduces synchronization forthe latter flows.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26812 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Create persistent INTx handlerA vulnerability exists where the eventfd for INTx signaling can bedeconfigured, which unregisters the IRQ handler but still allowseventfds to be signaled with a NULL context through the SET_IRQS ioctlor through unmask irqfd if the device interrupt is pending.Ideally this could be solved with some additional locking; the igatemutex serializes the ioctl and config space accesses, and the interrupthandler is unregistered relative to the trigger, but the irqfd pathruns asynchronous to those. The igate mutex cannot be acquired from theatomic context of the eventfd wake function. Disabling the irqfdrelative to the eventfd registration is potentially incompatible withexisting userspace.As a result, the solution implemented here moves configuration of theINTx interrupt handler to track the lifetime of the INTx context objectand irq_type configuration, rather than registration of a particulartrigger eventfd. Synchronization is added between the ioctl path andeventfd_signal() wrapper such that the eventfd trigger can bedynamically updated relative to in-flight interrupts or irqfd callbacks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26820 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missedIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTERhandler cannot perform VF register successfully as the register callis received before netvsc_probe is finished. This is because weregister register_netdevice_notifier() very early( even beforevmbus_driver_register()).To fix this, we try to register each such matching VF( if it is visibleas a netdevice) at the end of netvsc_probe.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26993 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fs: sysfs: Fix reference leak in sysfs_break_active_protection()The sysfs_break_active_protection() routine has an obvious referenceleak in its error path. If the call to kernfs_find_and_get() fails thenkn will be NULL, so the companion sysfs_unbreak_active_protection()routine won't get called (and would only cause an access violation bytrying to dereference kn->parent if it was called). As a result, thereference to kobj acquired at the start of the function will never bereleased.Fix the leak by adding an explicit kobject_put() call when kn is NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-31076 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offlineThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness ofinterrupt affinity reconfiguration via procfs. Instead, the change isdeferred until the next instance of the interrupt being triggered on theoriginal CPU.When the interrupt next triggers on the original CPU, the new affinity isenforced within __irq_move_irq(). A vector is allocated from the new CPU,but the old vector on the original CPU remains and is not immediatelyreclaimed. Instead, apicd->move_in_progress is flagged, and the reclaimingprocess is delayed until the next trigger of the interrupt on the new CPU.Upon the subsequent triggering of the interrupt on the new CPU,irq_complete_move() adds a task to the old CPU's vector_cleanup list if itremains online. Subsequently, the timer on the old CPU iterates over itsvector_cleanup list, reclaiming old vectors.However, a rare scenario arises if the old CPU is outgoing before theinterrupt triggers again on the new CPU.In that case irq_force_complete_move() is not invoked on the outgoing CPUto reclaim the old apicd->prev_vector because the interrupt isn't currentlyaffine to the outgoing CPU, and irq_needs_fixup() returns false. Eventhough __vector_schedule_cleanup() is later called on the new CPU, itdoesn't reclaim apicd->prev_vector; instead, it simply resets bothapicd->move_in_progress and apicd->prev_vector to 0.As a result, the vector remains unreclaimed in vector_matrix, leading to aCPU vector leak.To address this issue, move the invocation of irq_force_complete_move()before the irq_needs_fixup() call to reclaim apicd->prev_vector, if theinterrupt is currently or used to be affine to the outgoing CPU.Additionally, reclaim the vector in __vector_schedule_cleanup() as well,following a warning message, although theoretically it should never seeapicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37891 Severity: Moderate CVSS3 score: 4.4

Description: urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).

CVE-2024-38546 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm: vc4: Fix possible null pointer dereferenceIn vc4_hdmi_audio_init() of_get_address() may returnNULL which is later dereferenced. Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38547 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binariesThe allocation failure of mycs->yuv_scaler_binary in load_video_binaries()is followed with a dereference of mycs->yuv_scaler_binary after thefollowing call chain:sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()In unload_video_binaries(), it calls to ia_css_binary_unload with argument&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to thesame memory slot as mycs->yuv_scaler_binary. Thus, a null-pointerdereference is triggered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38550 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: kirkwood: Fix potential NULL dereferenceIn kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL ifCONFIG_PLAT_ORION macro is not defined.Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38558 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix overwriting ct original tuple for ICMPv6OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structurewith the metadata like conntrack state, input port, recirculation id,etc. Then the packet itself gets parsed to populate the rest of thekeys from the packet headers.Whenever the packet parsing code starts parsing the ICMPv6 header, itfirst zeroes out fields in the key corresponding to Neighbor Discoveryinformation even if it is not an ND packet.It is an 'ipv6.nd' field. However, the 'ipv6' is a union that sharesthe space between 'nd' and 'ct_orig' that holds the original tupleconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.ND packets should not normally have conntrack state, so it's fine toshare the space, but normal ICMPv6 Echo packets or maybe other types ofICMPv6 can have the state attached and it should not be overwritten.The issue results in all but the last 4 bytes of the destinationaddress being wiped from the original conntrack tuple leading toincorrect packet matching and potentially executing wrong actionsin case this packet recirculates within the datapath or goes backto userspace.ND fields should not be accessed in non-ND packets, so not clearingthem should be fine. Executing memset() only for actual ND packets toavoid the issue.Initializing the whole thing before parsing is needed because ND packetmay not contain all the options.The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn'taffect packets entering OVS datapath from network interfaces, becausein this case CT metadata is populated from skb after the packet isalready parsed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38571 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:thermal/drivers/tsens: Fix null pointer dereferencecompute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to nullpointer dereference (if DEBUG or DYNAMIC_DEBUG set).Fix this bug by adding null pointer check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38580 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:epoll: be better about file lifetimesepoll can call out to vfs_poll() with a file pointer that may race withthe last 'fput()'. That would make f_count go down to zero, and whilethe ep->mtx locking means that the resulting file pointer tear-down willbe blocked until the poll returns, it means that f_count is alreadydead, and any use of it won't actually get a reference to the file anymore: it's dead regardless.Make sure we have a valid ref on the file pointer before we call down tovfs_poll() from the epoll routines.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38597 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:eth: sungem: remove .ndo_poll_controller to avoid deadlocksErhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20cgem_poll_controller() disables interrupts, which may sleep.We can't sleep in netpoll, it has interrupts disabled completely.Strangely, gem_poll_controller() doesn't even poll the completions,and instead acts as if an interrupt has fired so it just schedulesNAPI and exits. None of this has been necessary for years, sincenetpoll invokes NAPI directly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38605 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: core: Fix NULL module pointer assignment at card initThe commit 81033c6b584b ("ALSA: core: Warn on empty module")introduced a WARN_ON() for a NULL module pointer passed at snd_cardobject creation, and it also wraps the code around it with '#ifdefMODULE'. This works in most cases, but the devils are always indetails. "MODULE" is defined when the target code (i.e. the soundcore) is built as a module; but this doesn't mean that the caller isalso built-in or not. Namely, when only the sound core is built-in(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),the passed module pointer is ignored even if it's non-NULL, andcard->module remains as NULL. This would result in the missing modulereference up/down at the device open/close, leading to a race with thecode execution after the module removal.For addressing the bug, move the assignment of card->module again outof ifdef. The WARN_ON() is still wrapped with ifdef because themodule can be really NULL when all sound drivers are built-in.Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it wouldlead to a false-positive NULL module check. Admittedly it won't catchperfectly, i.e. no check is performed when CONFIG_SND=y. But, it's noreal problem as it's only for debugging, and the condition is prettyrare.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38608 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix netif state handlingmlx5e_suspend cleans resources only if netif_device_present() returnstrue. However, mlx5e_resume changes the state of netif, viamlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.In the below case, the above leads to NULL-ptr Oops[1] and memoryleaks:mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason.ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :(Hence, clean resources in this case as well.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at0xffffffffffffffd6.RSP: 0018:ffff888178aaf758 EFLAGS: 00010246Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? asm_exc_page_fault+0x22/0x30 notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] probe_one+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+0xbf/0x210 ? kernfs_create_link+0x5d/0xa0 ? sysfs_do_create_link_sd+0x60/0xc0 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38615 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: exit() callback is optionalThe exit() callback is optional and shouldn't be called without checkinga valid pointer first.Also, we must clear freq_table pointer even if the exit() callback isn'tpresent.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38662 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don't intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39471 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: add error handle to avoid out-of-boundsif the sdma_v4_0_irq_id_to_seq return -EINVAL, the process shouldbe stop to avoid out-of-bounds read, so directly return -EINVAL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40934 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()Fix a memory leak on logi_dj_recv_send_report() error path.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40978 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix crash while reading debugfs attributeThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directlyon a __user pointer, which results into the crash.To fix this issue, use a small local stack buffer for sprintf() and thencall simple_read_from_buffer(), which in turns make the copy_to_user()call.BUG: unable to handle page fault for address: 00007f4801111000PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0Oops: 0002 [#1] PREEMPT SMP PTIHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023RIP: 0010:memcpy_orig+0xcd/0x130RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000fRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fffR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7afFS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7f4800f20b4d

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41002 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/sec - Fix memory leak for sec resource releaseThe AIV is one of the SEC resources. When releasing resources,it need to release the AIV resources at the same time.Otherwise, memory leakage occurs.The aiv resource release is added to the sec resource releasefunction.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41006 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix a memory leak in nr_heartbeat_expiry()syzbot reported a memory leak in nr_create() [0].Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")added sock_hold() to the nr_heartbeat_expiry() function, wherea) a socket has a SOCK_DESTROY flag orb) a listening socket has a SOCK_DEAD flag.But in the case "a," when the SOCK_DESTROY flag is set, the file descriptorhas already been closed and the nr_release() function has been called.So it makes no sense to hold the reference count because no one willcall another nr_destroy_socket() and put it as in the case "b."nr_connect nr_establish_data_link nr_start_heartbeatnr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket()To fix the memory leak, let's call sock_hold() only for a listening socket.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41023 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix task_struct reference leakDuring the execution of the following stress test with linux-rt:stress-ng --cyclic 30 --timeout 30 --minimize --quietkmemleak frequently reported a memory leak concerning the task_struct:unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76The issue occurs in start_dl_timer(), which increments the task_structreference count and sets a timer. The timer callback, dl_task_timer,is supposed to decrement the reference count upon expiration. However,if enqueue_task_dl() is called before the timer expires and cancels it,the reference count is not decremented, leading to the leak.This patch fixes the reference leak by ensuring the task_structreference count is properly decremented when the timer is canceled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41039 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Fix overflow checking of wmfw headerFix the checking that firmware file buffer is large enough for thewmfw header, to prevent overrunning the buffer.The original code tested that the firmware data buffer containedenough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footerBut wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 andHalo Core the equivalent struct is wmfw_adsp2_sizes, which is4 bytes longer. So the length check didn't guarantee that thereare enough bytes in the firmware buffer for a header withwmfw_adsp2_sizes.This patch splits the length check into three separate parts. Eachof the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checkedseparately before they are used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41042 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prefer nft_chain_validatenft_chain_validate already performs loop detection because a cycle willresult in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).It also follows maps via ->validate callback in nft_lookup, so thereappears no reason to iterate the maps again.nf_tables_check_loops() and all its helper functions can be removed.This improves ruleset load time significantly, from 23s down to 12s.This also fixes a crash bug. Old loop detection code can result inunbounded recursion:BUG: TASK stack guard page was hit at ....Oops: stack guard page: 0000 [#1] PREEMPT SMP KASANCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1[..]with a suitable ruleset during validation of register stores.I can't see any actual reason to attempt to check for this fromnft_validate_register_store(), at this point the transaction is still inprogress, so we don't have a full picture of the rule graph.For nf-next it might make sense to either remove it or make this dependon table->validate_state in case we could catch an error earlier(for improved error reporting to userspace).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41065 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Whitelist dtl slub object for copying to userspaceReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled asshown below. kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ ... GPRs omitted ... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Call Trace: usercopy_abort+0x74/0xb0 (unreliable) __check_heap_object+0xf8/0x120 check_heap_object+0x218/0x240 __check_object_size+0x84/0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupt: 3000 at 0x7fff81f3ab34Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")requires that only whitelisted areas in slab/slub objects can be copied touserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.Dtl contains hypervisor dispatch events which are expected to be read byprivileged users. Hence mark this safe for user access.Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist theentire object.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45306 Severity: Moderate CVSS3 score: 4.4

Description: Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end ofa line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer atthe specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2024-46702 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Mark XDomain as unplugged when router is removedI noticed that when we do discrete host router NVM upgrade and it getshot-removed from the PCIe side as a result of NVM firmware authentication,if there is another host connected with enabled paths we hang in tearingthem down. This is due to fact that the Thunderbolt networking driveralso tries to cleanup the paths and ends up blocking intb_disconnect_xdomain_paths() waiting for the domain lock.However, at this point we already cleaned the paths in tb_stop() sothere is really no need for tb_disconnect_xdomain_paths() to do thatanymore. Furthermore it already checks if the XDomain is unplugged andbails out early so take advantage of that and mark the XDomain asunplugged when we remove the parent router.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46754 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Remove tst_run from lwt_seg6local_prog_ops.The syzbot reported that the lwt_seg6 related BPF ops can be invokedvia bpf_test_run() without without entering input_action_end_bpf()first.Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCALprobably didn't work since it was introduced in commit 04d4b274e2a("ipv6: sr: Add seg6local action End.BPF"). The reason is that theper-CPU variable seg6_bpf_srh_states::srh is never assigned in the selftest case but each BPF function expects it.Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47794 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tailcall infinite loop caused by freplaceThere is a potential infinite loop issue that can occur when using acombination of tail calls and freplace.In an upcoming selftest, the attach target for entry_freplace oftailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call inentry_freplace leads to entry_tc. This results in an infinite loop:entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.The problem arises because the tail_call_cnt in entry_freplace resets tozero each time entry_freplace is executed, causing the tail call mechanismto never terminate, eventually leading to a kernel panic.To fix this issue, the solution is twofold:1. Prevent updating a program extended by an freplace program to a prog_array map.2. Prevent extending a program that is already part of a prog_array map with an freplace program.This ensures that:* If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.* If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.Moreover, an extension program should not be tailcalled. As such, return-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to aprog_array map.Additionally, fix a minor code style issue by replacing eight spaces with atab for proper formatting.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49569 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: unquiesce admin_q before destroy itKernel will hang on destroy admin_q while we create ctrl failed, suchas following calltrace:PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002bThis due to we have quiesced admi_q before cancel requests, but forgotto unquiesce before destroy it, as a result we fail to drain thepending requests, and hang on blk_mq_freeze_queue_wait() forever. Heretry to reuse nvme_rdma_teardown_admin_queue() to fix this issue andsimplify the code.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49968 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: filesystems without casefold feature cannot be mounted with siphashWhen mounting the ext4 filesystem, if the default hash version is set toDX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50117 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: Guard against bad data for ATIF ACPI methodIf a BIOS provides bad data in response to an ATIF method callthis causes a NULL pointer dereference in the caller.```? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)? exc_page_fault (arch/x86/mm/fault.c:1542)? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu```It has been encountered on at least one system, so guard for it.(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50153 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: core: Fix null-ptr-deref in target_alloc_device()There is a null-ptr-deref issue reported by KASAN:BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0... entry_SYSCALL_64_after_hwframe+0x76/0x7eIn target_alloc_device(), if allocing memory for dev queues fails, thendev will be freed by dev->transport->free_device(), but dev->transportis not initialized at that time, which will lead to a null pointerreference problem.Fixing this bug by freeing dev with hba->backend->ops->free_device().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50162 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: devmap: provide rxq after redirectrxq contains a pointer to the device from wherethe redirect happened. Currently, the BPF programthat was executed after a redirect via BPF_MAP_TYPE_DEVMAP*does not have it set.This is particularly bad since accessing ingress_ifindex, e.g.SEC("xdp")int prog(struct xdp_md *pkt){ return bpf_redirect_map(&dev_redirect_map, 0, 0);}SEC("xdp/devmap")int prog_after_redirect(struct xdp_md *pkt){ bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS;}depends on access to rxq, so a NULL pointer gets dereferenced:<1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000<1>[ 574.475188] #PF: supervisor read access in kernel mode<1>[ 574.475194] #PF: error_code(0x0000) - not-present page<6>[ 574.475199] PGD 0 P4D 0<4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23<4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023<4>[ 574.475231] Workqueue: mld mld_ifc_work<4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b<4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206<4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000<4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0<4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001<4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000<4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000<4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000<4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0<4>[ 574.475303] PKRU: 55555554<4>[ 574.475306] Call Trace:<4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70<4>[ 574.475329] ? page_fault_oops+0x180/0x4c0<4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490<4>[ 574.475346] ? kmem_cache_free+0x257/0x280<4>[ 574.475357] ? exc_page_fault+0x67/0x150<4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30<4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475386] bq_xmit_all+0x158/0x420<4>[ 574.475397] __dev_flush+0x30/0x90<4>[ 574.475407] veth_poll+0x216/0x250 [veth]<4>[ 574.475421] __napi_poll+0x28/0x1c0<4>[ 574.475430] net_rx_action+0x32d/0x3a0<4>[ 574.475441] handle_softirqs+0xcb/0x2c0<4>[ 574.475451] do_softirq+0x40/0x60<4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70<4>[ 574.475471] __dev_queue_xmit+0x268/0xe40<4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420<4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0<4>[ 574.475502] ip6_finish_output2+0x2be/0x640<4>[ 574.475512] ? nf_hook_slow+0x42/0xf0<4>[ 574.475521] ip6_finish_output+0x194/0x300<4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10<4>[ 574.475538] mld_sendpack+0x17c/0x240<4>[ 574.475548] mld_ifc_work+0x192/0x410<4>[ 574.475557] process_one_work+0x15d/0x380<4>[ 574.475566] worker_thread+0x29d/0x3a0<4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475587] kthread+0xcd/0x100<4>[ 574.475597] ? __pfx_kthread+0x10/0x10<4>[ 574.475606] ret_from_fork+0x31/0x50<4>[ 574.475615] ? __pfx_kthread+0x10/0x10<4>[ 574.475623] ret_from_fork_asm+0x1a/0x---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56574 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: ts2020: fix null-ptr-deref in ts2020_probe()KASAN reported a null-ptr-deref issue when executing the followingcommand: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...The cause of the problem is that when using sysfs to dynamically registeran i2c device, there is no platform data, but the probe process of ts2020needs to use platform data, resulting in a null pointer being accessed.Solve this problem by adding checks to platform data.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56588 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Create all dump files during debugfs initializationFor the current debugfs of hisi_sas, after user triggers dump, thedriver allocate memory space to save the register information and createdebugfs files to display the saved information. In this process, thedebugfs files created after each dump.Therefore, when the dump is triggered while the driver is unbind, thefollowing hang occurs:[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[67840.862947] Mem abort info:[67840.865855] ESR = 0x0000000096000004[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits[67840.875125] SET = 0, FnV = 0[67840.878291] EA = 0, S1PTW = 0[67840.881545] FSC = 0x04: level 0 translation fault[67840.886528] Data abort info:[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[67841.003628] pc : down_write+0x30/0x98[67841.007546] lr : start_creating.part.0+0x60/0x198[67841.012495] sp : ffff8000b979ba20[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0[67841.089759] Call trace:[67841.092456] down_write+0x30/0x98[67841.096017] start_creating.part.0+0x60/0x198[67841.100613] debugfs_create_dir+0x48/0x1f8[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw][67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw][67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw][67841.125115] full_proxy_write+0x68/0xc8[67841.129175] vfs_write+0xd8/0x3f0[67841.132708] ksys_write+0x70/0x108[67841.136317] __arm64_sys_write+0x24/0x38[67841.140440] invoke_syscall+0x50/0x128[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0[67841.149273] do_el0_svc+0x24/0x38[67841.152773] el0_svc+0x38/0xd8[67841.156009] el0t_64_sync_handler+0xc0/0xc8[67841.160361] el0t_64_sync+0x1a4/0x1a8[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)[67841.170443] ---[ end trace 0000000000000000 ]---To fix this issue, create all directories and files during debugfsinitialization. In this way, the driver only needs to allocate memoryspace to save information each time the user triggers dumping.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56599 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: avoid NULL pointer error during sdio removeWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdioworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ONis set to yes, kernel panic will happen:Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2cThis is because during 'rmmod ath10k', ath10k_sdio_remove() will callath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()will finally be called in ath10k_core_destroy(). This function will freestruct cfg80211_registered_device *rdev and all its members, includingwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdioworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.After device release, destroy_workqueue() will use NULL pointer then thekernel panic happen.Call trace:ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueueNeed to call destroy_workqueue() before ath10k_core_destroy(), freethe work queue buffer first and then free pointer of work queue byath10k_core_destroy(). This order matches the error path order inath10k_sdio_probe().No work will be queued on sdio workqueue between it is destroyed andath10k_core_destroy() is called. Based on the call_stack above, thereason is:Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() andath10k_sdio_irq_disable() will queue work on sdio workqueue.Sleep timer will be deleted before ath10k_core_destroy() inath10k_hif_power_down().ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().ath10k_core_unregister() will call ath10k_hif_power_down() to stop hifbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57883 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: independent PMD page table shared countThe folio refcount may be increased unexpectly through try_get_folio() bycaller such as split_huge_pages. In huge_pmd_unshare(), we use refcountto check whether a pmd page table is shared. The check is incorrect ifthe refcount is increased by the above caller, and this can cause the pagetable leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198The issue may be triggered by damon, offline_page, page_idle, etc, whichwill increase the refcount of page table.1. The page table itself will be discarded after reporting the "nonzero mapcount".2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.Fix it by introducing independent PMD page table shared count. Asdescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscvpmds, so we can reuse the field as pt_share_count.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21957 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla1280: Fix kernel oops when debug level > 2A null dereference or oops exception will eventually occur when qla1280.cdriver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. Ithink its clear from the code that the intention here is sg_dma_len(s) notlength of sg_next(s) when printing the debug info.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22057 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: decrease cached dst counters in dst_releaseUpstream fix ac888d58869b ("net: do not delay dst_entries_add() indst_release()") moved decrementing the dst count from dst_destroy todst_release to avoid accessing already freed data in case of netnsdismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnelsare used, this fix is incomplete as the same issue will be seen forcached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30Fix this by invalidating the cache, and thus decrementing cached dstcounters, in dst_release too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37740 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add sanity check for agwidth in dbMountThe width in dmapctl of the AG is zero, it trigger a divide error whencalculating the control page level in dbAllocAG.To avoid this issue, add a check for agwidth in dbAllocAG.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37883 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Add check for get_zeroed_page()Add check for the return value of get_zeroed_page() insclp_console_init() to prevent null pointer dereference.Furthermore, to solve the memory leak caused by the loopallocation, add a free helper to do the free job.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37923 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix oob write in trace_seq_to_buffer()syzbot reported this bug:==================================================================BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 ....==================================================================It has been reported that trace_seq_to_buffer() tries to copy more datathan PAGE_SIZE to buf. Therefore, to prevent this, we should use thesmaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37927 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihidThere is a string parsing logic error which can lead to an overflow of hidor uid buffers. Comparing ACPIID_LEN against a total string length doesn'ttake into account the lengths of individual hid and uid buffers so thecheck is insufficient in some cases. For example if the length of hidstring is 4 and the length of the uid string is 260, the length of strwill be equal to ACPIID_LEN + 1 but uid string will overflow uid bufferwhich size is 256.The same applies to the hid string with length 13 and uid string withlength 250.Check the length of hid and uid strings separately to preventbuffer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37994 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix NULL pointer accessThis patch ensures that the UCSI driver waits for all pending tasks in theucsi_displayport_work workqueue to finish executing before proceeding withthe partner removal.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38034 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: correct the order of prelim_ref arguments in btrfs__prelim_refbtrfs_prelim_ref() calls the old and new reference variables in theincorrect order. This causes a NULL pointer dereference because oldrefis passed as NULL to trace_btrfs_prelim_ref_insert().Note, trace_btrfs_prelim_ref_insert() is being called with newref asoldref (and oldref as NULL) on purpose in order to print outthe values of newref.To reproduce:echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enablePerform some writeback operations.Backtrace:BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38042 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chnThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss canrun on multiple platforms having different DMA architectures.On some platforms there can be one FDQ for all flows in the RX channelwhile for others there is a separate FDQ for each flow in the RX channel.So far we have been relying on the skip_fdq argument ofk3_udma_glue_reset_rx_chn().Instead of relying on the user to provide this information, infer itbased on DMA architecture during k3_udma_glue_request_rx_chn() and save itin an internal flag 'single_fdq'. Use that flag atk3_udma_glue_reset_rx_chn() to deicide if the FDQ needsto be cleared for every flow or just for flow 0.Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.> ip link set eth1 down> ip link set eth0 down> ethtool -L eth0 rx 8> ip link set eth0 up> modprobe -r ti_am65_cpsw_nuss[ 103.045726] ------------[ cut here ]------------[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcasp drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 rfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool][ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.154709] sp : ffff8000826ebbc0[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000[ 103.229274] Call trace:[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss][ 103.244942] devm_action_release+0x14/0x20[ 103.249040] release_nodes+0x3c/0x68[ 103.252610] devres_release_all+0x8c/0xdc[ 103.256614] device_unbind_cleanup+0x18/0x60[ 103.260876] device_release_driver_internal+0xf8/0x178[ 103.266004] driver_detach+0x50/0x9c[ 103.269571] bus_remove_driver+0x6c/0xbc[ 103.273485] driver_unregister+0x30/0x60[ 103.277401] platform_driver_unregister+0x14/0x20[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss][ 103.288620] __arm64_sys_delete_module+0x17c/0x25c[ 103.293404] invoke_syscall+0x44/0x100[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0[ 103.301845] do_el0_svc+0x1c/0x28[ 103.305155] el0_svc+0x28/0x98---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38100 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:x86/iopl: Cure TIF_IO_BITMAP inconsistenciesio_bitmap_exit() is invoked from exit_thread() when a task exists orwhen a fork fails. In the latter case the exit_thread() cleans upresources which were allocated during fork().io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends upin tss_update_io_bitmap(). tss_update_io_bitmap() operates on thecurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,tss_update_io_bitmap() crashes with a NULL pointer dereference.There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap().Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().For paranoia sake, add a warning into tss_update_io_bitmap() to catchthe case, when that code is invoked with inconsistent state.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38135 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:serial: Fix potential null-ptr-deref in mlb_usio_probe()devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()does not check for this case, which could result in a NULL pointerdereference.Add NULL check after devm_ioremap() to prevent this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38152 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Clear table_sz when rproc_shutdownThere is case as below could trigger kernel dump:Use U-Boot to start remote processor(rproc) with resource tablepublished to a fixed address by rproc. After Kernel boots up,stop the rproc, load a new firmware which doesn't have resource table,and start rproc.When starting rproc with a firmware not have resource table,`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` willtrigger dump, because rproc->cache_table is set to NULL during the laststop operation, but rproc->table_sz is still valid.This issue is found on i.MX8MP and i.MX9.Dump as below:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000[0000000000000000] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] PREEMPT SMPModules linked in:CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38Hardware name: NXP i.MX8MPlus EVK board (DT)pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __pi_memcpy_generic+0x110/0x22clr : rproc_start+0x88/0x1e0Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19cClear rproc->table_sz to address the issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38215 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================Even though fbcon_init() checks beforehand if fb_match_mode() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38229 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: cxusb: no longer judge rbuf when the write failssyzbot reported a uninit-value in cxusb_i2c_xfer. [1]Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()will be executed to read rlen bytes of data from the dvb device into therbuf.In this case, although rlen is 1, the write operation failed which resultedin the dvb read operation not being executed, and ultimately variable i wasnot initialized.[1]BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38312 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It'sthen passed to fb_cvt_hperiod(), where it's used as a divider -- divisionby 0 will result in kernel oops. Add a sanity check for cvt.f_refresh toavoid such overflow...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38342 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:software node: Correct a OOB check in software_node_get_reference_args()software_node_get_reference_args() wants to get @index-th element, sothe property value requires at least '(index + 1) * sizeof(*ref)' bytesbut that can not be guaranteed by current OOB check, and may cause OOBfor malformed property.Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38345 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi operand cache leak in dswstate.cACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732I found an ACPI cache leak in ACPI early termination and boot continuing case.When early termination occurs due to malicious ACPI table, Linux kernelterminates ACPI function and continues to boot process. While kernel terminatesACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.Boot log of ACPI operand cache leak is as follows:>[ 0.585957] ACPI: Added _OSI(Module Device)>[ 0.587218] ACPI: Added _OSI(Processor Device)>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)>[ 0.597858] ACPI: Unable to start the ACPI Interpreter>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26>[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006>[ 0.609177] Call Trace:>[ 0.610063] ? dump_stack+0x5c/0x81>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b>[ 0.619293] ? acpi_terminate+0xa/0x14>[ 0.620394] ? acpi_init+0x2af/0x34f>[ 0.621616] ? __class_create+0x4c/0x80>[ 0.623412] ? video_setup+0x7f/0x7f>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27>[ 0.625861] ? do_one_initcall+0x4e/0x1a0>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f>[ 0.628972] ? rest_init+0x80/0x80>[ 0.630043] ? kernel_init+0xa/0x100>[ 0.631084] ? ret_from_fork+0x25/0x30>[ 0.633343] vgaarb: loaded>[ 0.635036] EDAC MC: Ver: 3.0.0>[ 0.638601] PCI: Probing PCI hardware>[ 0.639833] PCI host bridge to bus 0000:00>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]> ... Continue to boot and log is omitted ...I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()function uses walk_state->operand_index for start position of the top, butacpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.Therefore, this causes acpi operand memory leak.This cache leak causes a security threat because an old kernel (<= 4.9) showsmemory locations of kernel functions in stack dump. Some malicious userscould use this information to neutralize kernel ASLR.I made a patch to fix ACPI operand cache leak.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38591 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-5916 Severity: Moderate CVSS3 score: 4.4

Description: A vulnerability has been identified in the libarchive library. This flaw involves an integer overflow that can be triggered when processing a Web Archive (WARC) file that claims to have more than INT64_MAX - 4 content bytes. An attacker could craft a malicious WARC archive to induce this overflow, potentially leading to unpredictable program behavior, memory corruption, or a denial-of-service condition within applications that process such archives using libarchive. This bug affects libarchive versions prior to 3.8.0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libarchive13 > 0-0 (version in image is 3.5.1-150400.3.21.1).

CVE-2020-13632 Severity: Moderate CVSS3 score: 4.3

Description: ext/fts3/fts3_snippet.c in SQLite before 3.32.0 has a NULL pointer dereference via a crafted matchinfo() query.

Packages affected:

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

CVE-2020-9327 Severity: Moderate CVSS3 score: 4.3

Description: In SQLite 3.31.1, isAuxiliaryVtabOperator allows attackers to trigger a NULL pointer dereference and segmentation fault because of generated column optimizations.

Packages affected:

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

CVE-2024-26715 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspendIn current scenario if Plug-out and Plug-In performed continuouslythere could be a chance while checking for dwc->gadget_driver indwc3_gadget_suspend, a NULL pointer dereference may occur.Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadgetCPU1 basically clears the variable and CPU2 checks the variable.Consider CPU1 is running and right before gadget_driver is clearedand in parallel CPU2 executes dwc3_gadget_suspend where it findsdwc->gadget_driver which is not NULL and resumes execution and thenCPU1 completes execution. CPU2 executes dwc3_disconnect_gadget whereit checks dwc->gadget_driver is already NULL because of which theNULL pointer deference occur.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26747 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: roles: fix NULL pointer issue when put module's referenceIn current design, usb role class driver will get usb_role_switch parent'smodule reference after the user get usb_role_switch device and put thereference after the user put the usb_role_switch device. However, theparent device of usb_role_switch may be removed before the user put theusb_role_switch. If so, then, NULL pointer issue will be met when the userput the parent module's reference.This will save the module pointer in structure of usb_role_switch. Then,we don't need to find module by iterating long relations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26836 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: think-lmi: Fix password opcode ordering for workstationsThe Lenovo workstations require the password opcode to be run beforethe attribute value is changed (if Admin password is enabled).Tested on some Thinkpads to confirm they are OK with this order too.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27024 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: fix WARNING in rds_conn_connect_if_downIf connection isn't established yet, get_mr() will fail, trigger connection afterget_mr().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35221 Severity: Moderate CVSS3 score: 4.3

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:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.54.1).

CVE-2024-46676 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Add poll mod list filling checkIn case of im_protocols value is 1 and tm_protocols value is 0 thiscombination successfully passes the check'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().But then after pn533_poll_create_mod_list() call in pn533_start_poll()poll mod list will remain empty and dev->poll_mod_count will remain 0which lead to division by zero.Normally no im protocol has value 1 in the mask, so this combination isnot expected by driver. But these protocol values actually come fromuserspace via Netlink interface (NFC_CMD_START_POLL operation). So abroken or malicious program may pass a message containing a "bad"combination of protocol parameter values so that dev->poll_mod_countis not incremented inside pn533_poll_create_mod_list(), thus leadingto division by zero.Call trace looks like:nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll()Add poll mod list filling check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50269 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY onexit") will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue->xceivsunxi_musb_probe() -> devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -> sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()3) register @musb_driver againmusb_probe() -> sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8713 Severity: Moderate CVSS3 score: 4.3

Description: PostgreSQL optimizer statistics allow a user to read sampled data within a view that the user cannot access. Separately, statistics allow a user to read sampled data that a row security policy intended to hide. PostgreSQL maintains statistics for tables by sampling data available in columns; this data is consulted during the query planning process. Prior to this release, a user could craft a leaky operator that bypassed view access control lists (ACLs) and bypassed row security policies in partitioning or table inheritance hierarchies. Reachable statistics data notably included histograms and most-common-values lists. CVE-2017-7484 and CVE-2019-10130 intended to close this class of vulnerability, but this gap remained. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.

Packages affected:

postgresql14 > 0-0 (version in image is 14.19-150200.5.61.1).
SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).

CVE-2021-37577 Severity: Moderate CVSS3 score: 4.2

Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49197 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:af_netlink: Fix shift out of bounds in group mask calculationWhen a netlink message is received, netlink_recvmsg() fills in the addressof the sender. One of the fields is the 32-bit bitfield nl_groups, whichcarries the multicast group on which the message was received. The leastsignificant bit corresponds to group 1, and therefore the highest groupthat the field can represent is 32. Above that, the UB sanitizer flags theout-of-bounds shift attempts.Which bits end up being set in such case is implementation defined, butit's either going to be a wrong non-zero value, or zero, which is at leastnot misleading. Make the latter choice deterministic by always setting to 0for higher-numbered multicast groups.To get information about membership in groups >= 32, userspace is expectedto use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFOsocket option.[0] https://lwn.net/Articles/147608/The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridgeWhich produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-40550 Severity: Moderate CVSS3 score: 4.2

Description: An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system's boot phase.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2024-49878 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXLWindow X". This confuses region_intersects(), which expects all "SystemRAM" resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be "Operation not permitted" instead of "Bad address". Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn't allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, "System RAM" is a descendant of "CXL Window 0" instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with "System RAM" not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- "CXL Window 0" ------------||-- "System RAM" --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- "System RAM" --||-- "CXL Window 0a" --|Where "CXL Window 0a" is part of the original "CXL Window 0" thatisn't covered by "System RAM".

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49934 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.nameIt's observed that a crash occurs during hot-remove a memory device,in which user is accessing the hugetlb. See calltrace as following:------------[ cut here ]------------WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc smirror dm_region_hash dm_log dm_modCPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:do_user_addr_fault+0x2a0/0x790Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200<...snip...>BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440<...snip...>? dentry_name+0x2fa/0x440vsnprintf+0x1f3/0x4f0vprintk_store+0x23a/0x540vprintk_emit+0x6d/0x330_printk+0x58/0x80dump_mapping+0x10b/0x1a0? __pfx_free_object_rcu+0x10/0x10__dump_page+0x26b/0x3e0? vprintk_emit+0xe0/0x330? _printk+0x58/0x80? dump_page+0x17/0x50dump_page+0x17/0x50do_migrate_range+0x2f7/0x7f0? do_migrate_range+0x42/0x7f0? offline_pages+0x2f4/0x8c0offline_pages+0x60a/0x8c0memory_subsys_offline+0x9f/0x1c0? lockdep_hardirqs_on+0x77/0x100? _raw_spin_unlock_irqrestore+0x38/0x60device_offline+0xe3/0x110state_store+0x6e/0xc0kernfs_fop_write_iter+0x143/0x200vfs_write+0x39f/0x560ksys_write+0x65/0xf0do_syscall_64+0x62/0x130Previously, some sanity check have been done in dump_mapping() beforethe print facility parsing '%pd' though, it's still possible to run intoan invalid dentry.d_name.name.Since dump_mapping() only needs to dump the filename only, retrieve itby itself in a safer way to prevent an unnecessary crash.Note that either retrieving the filename with '%pd' orstrncpy_from_kernel_nofault(), the filename could be unreliable.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-8006 Severity: Moderate CVSS3 score: 4.2

Description: Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libpcap1 > 0-0 (version in image is 1.10.1-150400.3.6.2).

CVE-2025-22079 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate l_tree_depth to avoid out-of-bounds accessThe l_tree_depth field is 16-bit (__le16), but the actual maximum depth islimited to OCFS2_MAX_PATH_DEPTH.Add a check to prevent out-of-bounds access if l_tree_depth has an invalidvalue, which may occur when reading from a corrupted mounted disk [1].

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22134 Severity: Moderate CVSS3 score: 4.2

Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-24014 Severity: Moderate CVSS3 score: 4.2

Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2022-49124 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: Work around an erratum on fast string copy instructionsA rare kernel panic scenario can happen when the following conditionsare met due to an erratum on fast string copy instructions:1) An uncorrected error.2) That error must be in first cache line of a page.3) Kernel must execute page_copy from the page immediately before thatpage.The fast string copy instructions ("REP; MOVS*") could consume anuncorrectable memory error in the cache line _right after_ the desiredregion to copy and raise an MCE.Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast stringcopy and will avoid such spurious machine checks. However, that is lesspreferable due to the permanent performance impact. Considering memorypoison is rare, it's desirable to keep fast string copy enabled until anMCE is seen.Intel has confirmed the following:1. The CPU erratum of fast string copy only applies to Skylake,Cascade Lake and Cooper Lake generations.Directly return from the MCE handler:2. Will result in complete execution of the "REP; MOVS*" with no dataloss or corruption.3. Will not result in another MCE firing on the next poisoned cache linedue to "REP; MOVS*".4. Will resume execution from a correct point in code.5. Will result in the same instruction that triggered the MCE firing asecond MCE immediately for any other software recoverable data fetcherrors.6. Is not safe without disabling the fast string copy, as the next faststring copy of the same buffer on the same CPU would result in a PANICMCE.This should mitigate the erratum completely with the only caveat thatthe fast string copy is disabled on the affected hyper thread thusperformance degradation.This is still better than the OS crashing on MCEs raised on anirrelevant process due to "REP; MOVS*' accesses in a kernel context,e.g., copy_page.Injected errors on 1st cache line of 8 anonymous pages of process'proc1' and observed MCE consumption from 'proc2' with no panic(directly returned).Without the fix, the host panicked within a few minutes on arandom 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49531 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:loop: implement ->free_diskEnsure that the lo_device which is stored in the gendisk privatedata is valid until the gendisk is freed. Currently the loop driveruses a lot of effort to make sure a device is not freed when it isstill in use, but to to fix a potential deadlock this will be relaxeda bit soon.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-46839 Severity: Moderate CVSS3 score: 4.1

Description: PCI devices can make use of a functionality called phantom functions,that when enabled allows the device to generate requests using the IDsof functions that are otherwise unpopulated. This allows a device toextend the number of outstanding requests.Such phantom functions need an IOMMU context setup, but failure tosetup the context is not fatal when the device is assigned. Notfailing device assignment when such failure happens can lead to theprimary device being assigned to a guest, while some of the phantomfunctions are assigned to a different domain.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2024-23850 Severity: Moderate CVSS3 score: 4.1

Description: In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36478 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'Writing 'power' and 'submit_queues' concurrently will trigger kernelpanic:Test script:modprobe null_blk nr_devices=0mkdir -p /sys/kernel/config/nullb/nullb0while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &while true; do echo 1 > power; echo 0 > power; doneTest result:BUG: kernel NULL pointer dereference, address: 0000000000000148Oops: 0000 [#1] PREEMPT SMPRIP: 0010:__lock_acquire+0x41d/0x28f0Call Trace: lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150This is because del_gendisk() can concurrent withblk_mq_update_nr_hw_queues():nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULLFix this problem by resuing the global mutex to protectnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38554 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix reference count leak issue of net_deviceThere is a reference count leak issue of the object "net_device" inax25_dev_device_down(). When the ax25 device is shutting down, theax25_dev_device_down() drops the reference count of net_device oneor zero times depending on if we goto unlock_put or not, which willcause memory leak.In order to solve the above issue, decrease the reference count ofnet_device after dev->ax25_ptr is set to null.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42155 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of protected- and secure-keysAlthough the clear-key of neither protected- nor secure-keys isaccessible, this key material should only be visible to the callingprocess. So wipe all copies of protected- or secure-keys from stack,even in case of an error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46679 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: check device is present when getting link settingsA sysfs reader can race with a device reset or removal, attempting toread device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5,state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).The device is not present, note lack of __LINK_STATE_PRESENT (0b10).This is the same sort of panic as observed in commit 4224cfd7fb65("net-sysfs: add check for netdevice being present to speed_show").There are many other callers of __ethtool_get_link_ksettings() whichdon't have a device presence check.Move this check into ethtool to protect all callers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49866 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:tracing/timerlat: Fix a race during cpuhp processingThere is another found exception that the "timerlat/1" thread wasscheduled on CPU0, and lead to timer corruption finally:```ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0Modules linked in:CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:debug_print_object+0x7d/0xb0...Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ```After tracing the scheduling event, it was discovered that the migrationof the "timerlat/1" thread was performed during thread creation. Furtheranalysis confirmed that it is because the CPU online processing forosnoise is implemented through workers, which is asynchronous with theoffline processing. When the worker was scheduled to create a thread, theCPU may has already been removed from the cpu_online_mask during the offlineprocess, resulting in the inability to select the right CPU:T1 | T2[CPUHP_ONLINE] | cpu_device_down()osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock()[CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() |To fix this, skip online processing if the CPU is already offline.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53197 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesA bogus device can provide a bNumConfigurations value that exceeds theinitial value used in usb_get_configuration for allocating dev->config.This can lead to out-of-bounds accesses later, e.g. inusb_destroy_configuration.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53221 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix null-ptr-deref in f2fs_submit_page_bio()There's issue as follows when concurrently installing the f2fs.komodule and mounting the f2fs file system:KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs]Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eAbove issue happens as the biset of the f2fs file system is notinitialized before register "f2fs_fs_type".To address above issue just register "f2fs_fs_type" at the last ininit_f2fs_fs(). Ensure that all f2fs file system resources areinitialized.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57940 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix the infinite loop in exfat_readdir()If the file system is corrupted so that a cluster is linked toitself in the cluster chain, and there is an unused directoryentry in the cluster, 'dentry' will not be incremented, causingcondition 'dentry < max_dentries' unable to prevent an infiniteloop.This infinite loop causes s_lock not to be released, and othertasks will hang, such as exfat_sync_fs().This commit stops traversing the cluster chain when there is unuseddirectory entry in the cluster to avoid this infinite loop.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22103 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer dereference in l3mdev_l3_rcvWhen delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3sThis may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354This is because l3mdev_l3_rcv() visit dev->l3mdev_ops afteripvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The processlike this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops |To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22113 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid journaling sb update on error if journal is destroyingPresently we always BUG_ON if trying to start a transaction on a journal markedwith JBD2_UNMOUNT, since this should never happen. However, while ltp runningstress tests, it was observed that in case of some error handling paths, it ispossible for update_super_work to start a transaction after the journal isdestroyed eg:(umount)ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT)Hence, introduce a new mount flag to indicate journal is destroying and only doa journaled (and deferred) update of sb if this flag is not set. Otherwise, justfallback to an un-journaled commit.Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updatesThis sequence is important as it ensures that, after this point, there is no sbupdate that might be journaled so it is safe to update the sb outside thejournal. (To avoid race discussed in 2d01ddc86606)Also, we don't need a similar check in ext4_grp_locked_error since it is onlycalled from mballoc and AFAICT it would be always valid to schedule work here.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37812 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Fix deadlock when using NCM gadgetThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").Under PREEMPT_RT the deadlock can be readily triggered by heavy networktraffic, for example using "iperf --bidir" over NCM ethernet link.The deadlock occurs because the threaded interrupt handler getspreempted by a softirq, but both are protected by the same spinlock.Prevent deadlock by disabling softirq during threaded irq handler.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37861 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38040 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:serial: mctrl_gpio: split disable_ms into sync and no_sync APIsThe following splat has been observed on a SAMA5D27 platform usingatmel_serial:BUG: sleeping function called from invalid context at kernel/irq/manage.c:738in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0preempt_count: 1, expected: 0INFO: lockdep is turned off.irq event stamp: 0hardirqs last enabled at (0): [<00000000>] 0x0hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7becsoftirqs last enabled at (0): [] copy_process+0x1ca0/0x7becsoftirqs last disabled at (0): [<00000000>] 0x0CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74Hardware name: Atmel SAMA5Workqueue: hci0 hci_power_on [bluetooth]Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28This warning is emitted when trying to toggle, at the highest level,some flow control (with serdev_device_set_flow_control) in a devicedriver. At the lowest level, the atmel_serial driver is usingserial_mctrl_gpio lib to enable/disable the corresponding IRQsaccordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due todisable_irq (called in mctrl_gpio_disable_ms) being possibly called insome atomic context (some tty drivers perform modem lines configurationin regions protected by port lock).Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking oneand a blocking one. Replace mctrl_gpio_disable_ms calls with therelevant version depending on whether the call is protected by some portlock.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38066 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: prevent BUG_ON by blocking retries on failed device resumesA cache device failing to resume due to mapping errors should not beretried, as the failure leaves a partially initialized policy object.Repeating the resume operation risks triggering BUG_ON when reloadingcache mappings into the incomplete policy object.Reproduce steps:1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.cat <> cmeta.xml EOFdmsetup create cmeta --table "0 8192 linear /dev/sdc 0"cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2dmsetup remove cmeta2. wipe the second array block of the mapping array to simulate data degradations.mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try bringing up the cache device. The resume is expected to fail due to the broken array block.dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dmsetup create cache --notabledmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup resume cache4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.dmsetup resume cacheKernel logs:(snip)------------[ cut here ]------------kernel BUG at drivers/md/dm-cache-policy-smq.c:752!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3RIP: 0010:smq_load_mapping+0x3e5/0x570Fix by disallowing resume operations for devices that failed theinitial attempt.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38073 Severity: Moderate CVSS3 score: 4.1

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38232 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix race between nfsd registration and exports_procAs of now nfsd calls create_proc_exports_entry() at start of init_nfsdand cleanup by remove_proc_entry() at last of exit_nfsd.Which causes kernel OOPs if there is race between below 2 operations:(i) exportfs -r(ii) mount -t nfsd none /proc/fs/nfsdfor 5.4 kernel ARM64:CPU 1:el1_irq+0xbc/0x180arch_counter_get_cntvct+0x14/0x18running_clock+0xc/0x18preempt_count_add+0x88/0x110prep_new_page+0xb0/0x220get_page_from_freelist+0x2d8/0x1778__alloc_pages_nodemask+0x15c/0xef0__vmalloc_node_range+0x28c/0x478__vmalloc_node_flags_caller+0x8c/0xb0kvmalloc_node+0x88/0xe0nfsd_init_net+0x6c/0x108 [nfsd]ops_init+0x44/0x170register_pernet_operations+0x114/0x270register_pernet_subsys+0x34/0x50init_nfsd+0xa8/0x718 [nfsd]do_one_initcall+0x54/0x2e0CPU 2 :Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010PC is at : exports_net_open+0x50/0x68 [nfsd]Call trace:exports_net_open+0x50/0x68 [nfsd]exports_proc_open+0x2c/0x38 [nfsd]proc_reg_open+0xb8/0x198do_dentry_open+0x1c4/0x418vfs_open+0x38/0x48path_openat+0x28c/0xf18do_filp_open+0x70/0xe8do_sys_open+0x154/0x248Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().and same is happening on latest 6.14 kernel as well:[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty...[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48...[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4...[ 285.469695] Call trace:[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)[ 285.470488] seq_read+0xe0/0x11c[ 285.470675] proc_reg_read+0x9c/0xf0[ 285.470874] vfs_read+0xc4/0x2fc[ 285.471057] ksys_read+0x6c/0xf4[ 285.471231] __arm64_sys_read+0x1c/0x28[ 285.471428] invoke_syscall+0x44/0x100[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0[ 285.471870] do_el0_svc_compat+0x1c/0x34[ 285.472073] el0_svc_compat+0x2c/0x80[ 285.472265] el0t_32_sync_handler+0x90/0x140[ 285.472473] el0t_32_sync+0x19c/0x1a0[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)[ 285.473422] ---[ end trace 0000000000000000 ]---It reproduced simply with below script:while [ 1 ]do/exportfs -rdone &while [ 1 ]doinsmod /nfsd.komount -t nfsd none /proc/fs/nfsdumount /proc/fs/nfsdrmmod nfsddone &So exporting interfaces to user space shall be done at last andcleanup at first place.With change there is no Kernel OOPs.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38336 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,running at UDMA/33.The issue can be reproduced by running the same command with a cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-53905 Severity: Moderate CVSS3 score: 4.1

Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-53906 Severity: Moderate CVSS3 score: 4.1

Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-7207 Severity: Moderate CVSS3 score: 4.0

Description: Debian's cpio contains a path traversal vulnerability. This issue was introduced by reverting CVE-2015-1197 patches which had caused a regression in --no-absolute-filenames. Upstream has since provided a proper fix to --no-absolute-filenames.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
cpio > 0-0 (version in image is 2.13-150400.3.6.1).

CVE-2024-50171 Severity: Moderate CVSS3 score: 4.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: systemport: fix potential memory leak in bcm_sysport_xmit()The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skbin case of dma_map_single() fails, add dev_kfree_skb() to fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-0938 Severity: Moderate CVSS3 score: 4.0

Description: The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).

CVE-2025-25724 Severity: Moderate CVSS3 score: 4.0

Description: list_item_verbose in tar/util.c in libarchive through 3.7.7 does not check an strftime return value, which can lead to a denial of service or unspecified other impact via a crafted TAR archive that is read with a verbose value of 2. For example, the 100-byte buffer may not be sufficient for a custom locale.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libarchive13 > 0-0 (version in image is 3.5.1-150400.3.21.1).

CVE-2025-38448 Severity: Moderate CVSS3 score: 4.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix race condition in TTY wakeupA race condition occurs when gs_start_io() calls either gs_start_rx() orgs_start_tx(), as those functions briefly drop the port_lock forusb_ep_queue(). This allows gs_close() and gserial_disconnect() to clearport.tty and port_usb, respectively.Use the null-safe TTY Port helper function to wake up TTY.Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-5244 Severity: Moderate CVSS3 score: 4.0

Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-5245 Severity: Moderate CVSS3 score: 4.0

Description: A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2023-48231 Severity: Low CVSS3 score: 3.9

Description: Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2023-48232 Severity: Low CVSS3 score: 3.9

Description: Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2025-5918 Severity: Low CVSS3 score: 3.9

Description: A vulnerability has been identified in the libarchive library. This flaw can be triggered when file streams are piped into bsdtar, potentially allowing for reading past the end of the file. This out-of-bounds read can lead to unintended consequences, including unpredictable program behavior, memory corruption, or a denial-of-service condition.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libarchive13 > 0-0 (version in image is 3.5.1-150400.3.21.1).

CVE-2024-34397 Severity: Low CVSS3 score: 3.8

Description: An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2024-36244 Severity: Low CVSS3 score: 3.8

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: extend minimum interval restriction to entire cycle tooIt is possible for syzbot to side-step the restriction imposed by theblamed commit in the Fixes: tag, because the taprio UAPI permits acycle-time different from (and potentially shorter than) the sum ofentry intervals.We need one more restriction, which is that the cycle time itself mustbe larger than N * ETH_ZLEN bit times, where N is the number of scheduleentries. This restriction needs to apply regardless of whether the cycletime came from the user or was the implicit, auto-calculated value, sowe move the existing "cycle == 0" check outside the "if "(!new->cycle_time)"branch. This way covers both conditions and scenarios.Add a selftest which illustrates the issue triggered by syzbot.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-11168 Severity: Low CVSS3 score: 3.7

Description: The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).

CVE-2023-48706 Severity: Moderate CVSS3 score: 3.6

Description: Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.

Packages affected:

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

CVE-2025-38067 Severity: Moderate CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:rseq: Fix segfault on registration when rseq_cs is non-zeroThe rseq_cs field is documented as being set to 0 by user-space prior toregistration, however this is not currently enforced by the kernel. Thiscan result in a segfault on return to user-space if the value stored inthe rseq_cs field doesn't point to a valid struct rseq_cs.The correct solution to this would be to fail the rseq registration whenthe rseq_cs field is non-zero. However, some older versions of glibcwill reuse the rseq area of previous threads without clearing therseq_cs field and will also terminate the process if the rseqregistration fails in a secondary thread. This wasn't caught in testingbecause in this case the leftover rseq_cs does point to a valid structrseq_cs.What we can do is clear the rseq_cs field on registration when it'snon-zero which will prevent segfaults on registration and won't breakthe glibc versions that reuse rseq areas on thread creation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40999 Severity: Low CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: Add validation for completion descriptors consistencyValidate that `first` flag is set only for the firstdescriptor in multi-buffer packets.In case of an invalid descriptor, a reset will occur.A new reset reason for RX data corruption has been added.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1147 Severity: Low CVSS3 score: 3.6

Description: A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2023-52698 Severity: Moderate CVSS3 score: 3.4

Description: In the Linux kernel, the following vulnerability has been resolved:calipso: fix memory leak in netlbl_calipso_add_pass()If IPv6 support is disabled at boot (ipv6.disable=1),the calipso_init() -> netlbl_calipso_ops_register() function isn't called,and the netlbl_calipso_ops_get() function always returns NULL.In this case, the netlbl_calipso_add_pass() function allocates memoryfor the doi_def variable but doesn't free it with the calipso_doi_free().BUG: memory leakunreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller[PM: merged via the LSM tree at Jakub Kicinski request]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38047 Severity: Moderate CVSS3 score: 3.4

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48844 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix leaking sent_cmd skbsent_cmd memory is not freed before freeing hci_dev causing it to leakit contents.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49780 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()If device_register() fails in tcm_loop_setup_hba_bus(), the name allocatedby dev_set_name() need be freed. As comment of device_register() says, itshould use put_device() to give up the reference in the error path. So fixthis by calling put_device(), then the name can be freed in kobject_cleanup().The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't needgoto error label in this case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49817 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: mhi: Fix memory leak in mhi_net_dellink()MHI driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch calls free_netdev() to fix it since netdev_privis used after unregister.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49829 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: fix fence ref countingWe leaked dependency fences when processes were beeing killed.Additional to that grab a reference to the last scheduled fence.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52652 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:NTB: fix possible name leak in ntb_register_device()If device_register() fails in ntb_register_device(), the device nameallocated by dev_set_name() should be freed. As per the comment indevice_register(), callers should use put_device() to give up thereference in the error path. So fix this by calling put_device() in theerror path so that the name can be freed in kobject_cleanup().As a result of this, put_device() in the error path ofntb_register_device() is removed and the actual error is returned.[mani: reworded commit message]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52653 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix a memleak in gss_import_v2_contextThe ctx->mech_used.data allocated by kmemdup is not freed in neithergss_import_v2_context nor it only caller gss_krb5_import_sec_context,which frees ctx on error.Thus, this patch reform the last call of gss_import_v2_context to thegss_krb5_import_ctx_v2, preventing the memleak while keepping the returnformation.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52835 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Bail out early if the request AUX area is out of boundWhen perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8'rb->aux_pages' allocated by kcalloc() is a pointer array which is used tomaintains AUX trace pages. The allocated page for this array is physicallycontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If thesize of pointer array crosses the limitation set by MAX_ORDER, it reveals aWARNING.So bail out early with -ENOMEM if the request AUX area is out of bound,e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26743 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/qedr: Fix qedr_create_user_qp error flowAvoid the following warning by making sure to free the allocatedresources in case that qedr_init_user_queue() fail.-----------[ cut here ]-----------WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ffRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0Call Trace:? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]? __warn+0x81/0x110? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]ib_uverbs_close+0x1f/0xb0 [ib_uverbs]__fput+0x94/0x250task_work_run+0x5c/0x90do_exit+0x270/0x4a0do_group_exit+0x2d/0x90get_signal+0x87c/0x8c0arch_do_signal_or_restart+0x25/0x100? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]exit_to_user_mode_loop+0x9c/0x130exit_to_user_mode_prepare+0xb6/0x100syscall_exit_to_user_mode+0x12/0x40do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x1470abe3ec6bCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6bRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470--[ end trace 888a9b92e04c5c97 ]--

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26877 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: xilinx - call finalize with bh disabledWhen calling crypto_finalize_request, BH should be disabled to avoidtriggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : crypto_finalize_request+0xa0/0x118 lr : crypto_finalize_request+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs last disabled at (40): [] el1_dbg+0x28/0x90 softirqs last enabled at (36): [] kernel_neon_begin+0x8c/0xf0 softirqs last disabled at (34): [] kernel_neon_begin+0x60/0xf0 ---[ end trace 0000000000000000 ]---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26901 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleaksyzbot identified a kernel information leak vulnerability indo_sys_name_to_handle() and issued the following report [1].[1]"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Bytes 18-19 of 20 are uninitializedMemory access of size 20 starts at ffff888128a46380Data copied to user address 0000000020000240"Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() tosolve the problem.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26937 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Reset queue_priority_hint on parkingOriginally, with strict in order execution, we could complete executiononly when the queue was empty. Preempt-to-busy allows replacement of anactive request that may complete before the preemption is processed byHW. If that happens, the request is retired from the queue, but thequeue_priority_hint remains set, preventing direct submission untilafter the next CS interrupt is processed.This preempt-to-busy race can be triggered by the heartbeat, which willalso act as the power-management barrier and upon completion allow us toidle the HW. We may process the completion of the heartbeat, and beginparking the engine before the CS event that restores thequeue_priority_hint, causing us to fail the assertion that it is MIN.<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))<0>[ 166.210781] Dumping ftrace buffer:<0>[ 166.210795] ---------------------------------...<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked<0>[ 167.303534] -0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040<0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }<0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }<0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))<0>[ 167.303811] ---------------------------------<4>[ 167.304722] ------------[ cut here ]------------<2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!<4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1<4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022<4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]<4>[ 16---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27000 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:serial: mxs-auart: add spinlock around changing cts stateThe uart_handle_cts_change() function in serial_core expects the callerto hold uport->lock. For example, I have seen the below kernel splat,when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27004 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:clk: Get runtime PM before walking tree during disable_unusedDoug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20The first thread is walking the clk tree and callingclk_pm_runtime_get() to power on devices required to read the clkhardware via struct clk_ops::is_enabled(). This thread holds the clkprepare_lock, and is trying to runtime PM resume a device, when it findsthat the device is in the process of resuming so the thread schedule()saway waiting for the device to finish resuming before continuing. Thesecond thread is runtime PM resuming the same device, but the runtimeresume callback is calling clk_prepare(), trying to grab theprepare_lock waiting on the first thread.This is a classic ABBA deadlock. To properly fix the deadlock, we mustnever runtime PM resume or suspend a device with the clk prepare_lockheld. Actually doing that is near impossible today because the globalprepare_lock would have to be dropped in the middle of the tree, thedevice runtime PM resumed/suspended, and then the prepare_lock grabbedagain to ensure consistency of the clk tree topology. If anythingchanges with the clk tree in the meantime, we've lost and will need tostart the operation all over again.Luckily, most of the time we're simply incrementing or decrementing theruntime PM count on an active device, so we don't have the chance toschedule away with the prepare_lock held. Let's fix this immediateproblem that can be---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35937 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: check A-MSDU format more carefullyIf it looks like there's another subframe in the A-MSDUbut the header isn't fully there, we can end up readingdata out of bounds, only to discard later. Make this abit more careful and check if the subframe header caneven be present.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37078 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential kernel bug due to lack of writeback flag waitingDestructive writes to a block device on which nilfs2 is mounted can causea kernel bug in the folio/page writeback start routine or writeback endroutine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 This is because when the log writer starts a writeback for segment summaryblocks or a super root block that use the backing device's page cache, itdoes not wait for the ongoing folio/page writeback, resulting in aninconsistent writeback state.Fix this issue by waiting for ongoing writebacks when puttingfolios/pages on the backing device into writeback state.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39489 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix memleak in seg6_hmac_init_algoseg6_hmac_init_algo returns without cleaning up the previous allocationsif one fails, so it's going to leak all that memory and the crypto tfms.Update seg6_hmac_exit to only free the memory when allocated, so we canreuse the code directly.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39490 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix missing sk_buff release in seg6_input_coreThe seg6_input() function is responsible for adding the SRH into apacket, delegating the operation to the seg6_input_core(). This functionuses the skb_cow_head() to ensure that there is sufficient headroom inthe sk_buff for accommodating the link-layer header.In the event that the skb_cow_header() function fails, theseg6_input_core() catches the error but it does not release the sk_buff,which will result in a memory leak.This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG dueto headroom too small after SRH push") and persists even after commit7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),where the entire seg6_input() code was refactored to deal with netfilterhooks.The proposed patch addresses the identified memory leak by requiring theseg6_input_core() function to release the sk_buff in the event thatskb_cow_head() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41013 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: don't walk off the end of a directory data blockThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entryto make sure don't stray beyond valid memory region. Before patching, theloop simply checks that the start offset of the dup and dep is within therange. So in a crafted image, if last entry is xfs_dir2_data_unused, wecan change dup->length to dup->length-1 and leave 1 byte of space. In thenext traversal, this space will be considered as dup or dep. We mayencounter an out of bound read when accessing the fixed members.In the patch, we make sure that the remaining bytes large enough to holdan unused entry before accessing xfs_dir2_data_unused andxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also makesure that the remaining bytes large enough to hold a dirent with asingle-byte name before accessing xfs_dir2_data_entry.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41015 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_check_dir_entry()This adds sanity checks for ocfs2_dir_entry to make sure all members ofocfs2_dir_entry don't stray beyond valid memory region.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41068 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix sclp_init() cleanup on failureIf sclp_init() fails it only partially cleans up: if there are multiplefailing calls to sclp_init() sclp_state_change_event will be added severaltimes to sclp_reg_list, which results in the following warning:------------[ cut here ]------------list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3...Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30Fix this by removing sclp_state_change_event from sclp_reg_list whensclp_init() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42070 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registersregister store validation for NFT_DATA_VALUE is conditional, however,the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. Thisonly requires a new helper function to infer the register type from theset datatype so this conditional check can be removed. Otherwise,pointer to chain object can be leaked through the registers.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42087 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleepThe ilitek-ili9881c controls the reset GPIO using the non-sleepinggpiod_set_value() function. This complains loudly when the GPIOcontroller needs to sleep. As the caller can sleep, usegpiod_set_value_cansleep() to fix the issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42311 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()Syzbot reports uninitialized value access issue as below:loop0: detected capacity change from 0 to 64=====================================================BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bBUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bIt missed to initialize .tz_secondswest, .cached_start and .cached_blocksfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45009 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only decrement add_addr_accepted for MPJ reqAdding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)... before decrementing the add_addr_accepted counter helped to find abug when running the "remove single subflow" subtest from themptcp_join.sh selftest.Removing a 'subflow' endpoint will first trigger a RM_ADDR, then thesubflow closure. Before this patch, and upon the reception of theRM_ADDR, the other peer will then try to decrement thisadd_addr_accepted. That's not correct because the attached subflows havenot been created upon the reception of an ADD_ADDR.A way to solve that is to decrement the counter only if the attachedsubflow was an MP_JOIN to a remote id that was not 0, and initiated bythe host receiving the RM_ADDR.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45010 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only mark 'subflow' endp as availableAdding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0)... before decrementing the local_addr_used counter helped to find a bugwhen running the "remove single address" subtest from the mptcp_join.shselftests.Removing a 'signal' endpoint will trigger the removal of all subflowslinked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() withrm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_usedcounter, which is wrong in this case because this counter is linked to'subflow' endpoints, and here it is a 'signal' endpoint that is beingremoved.Now, the counter is decremented, only if the ID is being used outsideof mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, andif the ID is not 0 -- local_addr_used is not taking into account theseones. This marking of the ID as being available, and the decrement isdone no matter if a subflow using this ID is currently available,because the subflow could have been closed before.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47671 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:USB: usbtmc: prevent kernel-usb-infoleakThe syzbot reported a kernel-usb-infoleak in usbtmc_write,we need to clear the structure before filling fields.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47672 Severity: Moderate CVSS3 score: 3.3

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47673 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedNot doing so will make us send a host command to the transport while thefirmware is not alive, which will trigger a WARNING.bad state = 0WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]Call Trace: iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50134 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLAReplace the fake VLA at end of the vbva_mouse_pointer_shape shape witha real VLA to fix a "memcpy: detected field-spanning write error" warning:[ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)[ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo][ 13.320038] Call Trace:[ 13.320173] hgsmi_update_pointer_shape [vboxvideo][ 13.320184] vbox_cursor_atomic_update [vboxvideo]Note as mentioned in the added comment it seems the original lengthcalculation for the allocated and send hgsmi buffer is 4 bytes too large.Changing this is not the goal of this patch, so this behavior is kept.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50236 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Fix memory leak in management txIn the current logic, memory is allocated for storing the MSDU contextduring management packet TX but this memory is not being freed duringmanagement TX completion. Similar leaks are seen in the management TXcleanup logic.Kmemleak reports this problem as below,unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20Free the memory during completion and cleanup to fix the leak.Protect the mgmt_pending_tx idr_remove() operation inath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar toother instances.Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53195 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Get rid of userspace_irqchip_in_useImproper use of userspace_irqchip_in_use led to syzbot hitting thefollowing WARN_ON() in kvm_timer_update_irq():WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459kvm_timer_update_irq+0x21c/0x394Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret);Theoretically, since userspace_irqchip_in_use's functionality can besimply replaced by '!irqchip_in_kernel()', get rid of the static keyto avoid the mismanagement, which also helps with the syzbot issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53198 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:xen: Fix the issue of resource not being properly released in xenbus_dev_probe()This patch fixes an issue in the function xenbus_dev_probe(). In thexenbus_dev_probe() function, within the if (err) branch at line 313, theprogram incorrectly returns err directly without releasing the resourcesallocated by err = drv->probe(dev, id). As the return value is non-zero,the upper layers assume the processing logic has failed. However, the probeoperation was performed earlier without a corresponding remove operation.Since the probe actually allocates resources, failing to perform the removeoperation could lead to problems.To fix this issue, we followed the resource release logic of thexenbus_dev_remove() function by adding a new block fail_remove before thefail_put block. After entering the branch if (err) at line 313, thefunction will use a goto statement to jump to the fail_remove block,ensuring that the previously acquired resources are correctly released,thus preventing the reference count leak.This bug was identified by an experimental static analysis tool developedby our team. The tool specializes in analyzing reference count operationsand detecting potential issues where resources are not properly managed.In this case, the tool flagged the missing release operation as apotential problem, which led to the development of this patch.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56751 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: release nexthop on device removalThe CI is hitting some aperiodic hangup at device removal time in thepmtu.sh self-test:unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0While the first suspect is the dst_cache, explicitly tracking the dstowing the last device reference via probes proved such dst is held bythe nexthop in the originating fib6_info.Similar to commit f5b51fe804ec ("ipv6: route: purge exception onremoval"), we need to explicitly release the originating fib info whendisconnecting a to-be-removed device from a live ipv6 dst: move thefib6_info cleanup into ip6_dst_ifdown().Tested running:./pmtu.sh cleanup_ipv6_exceptionin a tight loop for more than 400 iterations with no spat, running anunpatched kernel I observed a splat every ~10 iterations.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57908 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: kmx61: fix information leak in triggered bufferThe 'buffer' local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57910 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: vcnl4035: fix information leak in triggered bufferThe 'buffer' local array is used to push data to userspace from atriggered buffer, but it does not set an initial value for the singledata element, which is an u16 aligned to 8 bytes. That leaves at least4 bytes uninitialized even after writing an integer value withregmap_read().Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57912 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: pressure: zpa2326: fix information leak in triggered bufferThe 'sample' local struct is used to push data to user space from atriggered buffer, but it has a hole between the temperature and thetimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).This hole is never initialized.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1372 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
elfutils > 0-0 (version in image is 0.185-150400.5.3.1).

CVE-2025-1632 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability was found in libarchive up to 3.7.7. It has been classified as problematic. This affects the function list of the file bsdunzip.c. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libarchive13 > 0-0 (version in image is 3.5.1-150400.3.21.1).

CVE-2025-21981 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix memory leak in aRFS after resetFix aRFS (accelerated Receive Flow Steering) structures memory leak byadding a checker to verify if aRFS memory is already allocated whileconfiguring VSI. aRFS objects are allocated in two cases:- as part of VSI initialization (at probe), and- as part of reset handlingHowever, VSI reconfiguration executed during reset involves memoryallocation one more time, without prior releasing already allocatedresources. This led to the memory leak with the following signature:[root@os-delivery ~]# cat /sys/kernel/debug/kmemleakunreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [] __kmalloc_cache_noprof+0x275/0x340 [] ice_init_arfs+0x3a/0xe0 [ice] [] ice_vsi_cfg_def+0x607/0x850 [ice] [] ice_vsi_setup+0x5b/0x130 [ice] [] ice_init+0x1c1/0x460 [ice] [] ice_probe+0x2af/0x520 [ice] [] local_pci_probe+0x43/0xa0 [] work_for_cpu_fn+0x13/0x20 [] process_one_work+0x179/0x390 [] worker_thread+0x239/0x340 [] kthread+0xcc/0x100 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30 ...

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-3198 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-37839 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: remove wrong sb->s_sequence checkJournal emptiness is not determined by sb->s_sequence == 0 but rather bysb->s_start == 0 (which is set a few lines above). Furthermore 0 is avalid transaction ID so the check can spuriously trigger. Remove theinvalid WARN_ON.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37859 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: avoid infinite loop to schedule delayed workerWe noticed the kworker in page_pool_release_retry() was wakenup repeatedly and infinitely in production because of thebuggy driver causing the inflight less than 0 and warningus in page_pool_inflight()[1].Since the inflight value goes negative, it means we shouldnot expect the whole page_pool to get back to work normally.This patch mitigates the adverse effect by not reschedulingthe kworker when detecting the inflight negative inpage_pool_release_retry().[1][Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages...[Mon Feb 10 20:36:11 2025] Call Trace:[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---Note: before this patch, the above calltrace would flood thedmesg due to repeated reschedule of release_dw kworker.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37909 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Fix memleak issue when GSO enabledAlways map the `skb` to the LS descriptor. Previously skb wasmapped to EXT descriptor when the number of fragments is zero withGSO enabled. Mapping the skb to EXT descriptor prevents it frombeing freed, leading to a memory leak

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38099 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/brokenA SCO connection without the proper voice_setting can causethe controller to lock up.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38528 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject %p% format string in bprintf-like helpersstatic const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt));The above BPF program isn't rejected and causes a kernel warning atruntime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0This happens because bpf_bprintf_prepare skips over the second %,detected as punctuation, while processing %p. This patch fixes it bynot skipping over punctuation. %\x00 is then processed in the nextiteration and rejected.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2019-19925 Severity: Low CVSS3 score: 3.3

Description: zipfileUpdate in ext/misc/zipfile.c in SQLite 3.30.1 mishandles a NULL pathname during an update of a ZIP archive.

Packages affected:

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

CVE-2019-20633 Severity: Low CVSS3 score: 3.3

Description: GNU patch through 2.7.6 contains a free(p_line[p_end]) Double Free vulnerability in the function another_hunk in pch.c that can cause a denial of service via a crafted patch file. NOTE: this issue exists because of an incomplete fix for CVE-2018-6952.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
patch > 0-0 (version in image is 2.7.6-150000.5.6.1).

CVE-2022-48642 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()It seems to me that percpu memory for chain stats started leaking sincecommit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority tohardware priority") when nft_chain_offload_priority() returned an error.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48698 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix memory leak when using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. Fix this up by properlycalling dput().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48808 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: fix panic when DSA master device unbinds on shutdownRafael reports that on a system with LX2160A and Marvell DSA switches,if a reboot occurs while the DSA master (dpaa2-eth) is up, the followingpanic can be seen:systemd-shutdown[1]: Rebooting.Unable to handle kernel paging request at virtual address 00a0000800000041[00a0000800000041] address between user and kernel address rangesInternal error: Oops: 96000004 [#1] PREEMPT SMPCPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32pc : dsa_slave_netdevice_event+0x130/0x3e4lr : raw_notifier_call_chain+0x50/0x6cCall trace: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 __do_sys_reboot+0x1cc/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17cIt can be seen from the stack trace that the problem is that thederegistration of the master causes a dev_close(), which gets notifiedas NETDEV_GOING_DOWN to dsa_slave_netdevice_event().But dsa_switch_shutdown() has already run, and this has unregistered theDSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts tocall dev_close_many() on those slave interfaces, leading to the problem.The previous attempt to avoid the NETDEV_GOING_DOWN on the master afterdsa_switch_shutdown() was called seems improper. Unregistering the slaveinterfaces is unnecessary and unhelpful. Instead, after the slaves havestopped being uppers of the DSA master, we can now reset to NULL themaster->dsa_ptr pointer, which will make DSA start ignoring all futurenotifier events on the master.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49020 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: Fix a potential socket leak in p9_socket_openBoth p9_fd_create_tcp() and p9_fd_create_unix() will callp9_socket_open(). If the creation of p9_trans_fd fails,p9_fd_create_tcp() and p9_fd_create_unix() will return anerror directly instead of releasing the cscoket, which willresult in a socket leak.This patch adds sock_release() to fix the leak issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49539 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: ser: fix CAM leaks occurring in L2 resetThe CAM, meaning address CAM and bssid CAM here, will get leaks duringSER (system error recover) L2 reset process and ieee80211_restart_hw()which is called by L2 reset process eventually.The normal flow would be like-> add interface (acquire 1)-> enter ips (release 1)-> leave ips (acquire 1)-> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>The ieee80211_restart_hw() flow (under connection)-> ieee80211 reconfig-> add interface (acquire 1)-> leave ips (acquire 1)-> connection (occupy (A) + 2) <(B) 1 more leak>Originally, CAM is released before HW restart only if connection is undersecurity. Now, release CAM whatever connection it is to fix leak in (A).OTOH, check if CAM is already valid to avoid acquiring multiple times tofix (B).Besides, if AP mode, release address CAM of all stations before HW restart.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49619 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: sfp: fix memory leak in sfp_probe()sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). Whendevm_add_action() fails, sfp is not freed, which leads to a memory leak.We should use devm_add_action_or_reset() instead of devm_add_action().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49620 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix possible refcount leak in tipc_sk_create()Free sk in case tipc_sk_insert() fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49837 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix memory leaks in __check_func_callkmemleak reports this issue:unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root case here is: In function prepare_func_exit(), the callee isnot released in the abnormal scenario after "state->curframe--;". Tofix, move "state->curframe--;" to the very bottom of the function,right when we free callee and reset frame[] pointer to NULL, as Andriisuggested.In addition, function __check_func_call() has a similar problem. Inthe abnormal scenario before "state->curframe++;", the callee alsoshould be released by free_func_state().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49979 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix refcount bug in sk_psock_get (2)Syzkaller reports refcount bug as follows:------------[ cut here ]------------refcount_t: saturated; leaking memory.WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19Modules linked in:CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel willreplaces TCP with SMC. In order to forward wakeupsmc socket waitqueue after fallback, kernel will setsclcsk->sk_user_data to origin smc socket insmc_fback_replace_callbacks().Later, in shutdown syscall, kernel will callssk_psock_get(), which treats the clcsk->sk_user_dataas psock type, triggering the refcnt warning.So, the root cause is that smc and psock, both will usesk_user_data field. So they will mismatch this fieldeasily.This patch solves it by using another bit(defined asSK_USER_DATA_PSOCK) in PTRMASK, to mark whethersk_user_data points to a psock object or not.This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e("net, sk_msg: Clear sk_user_data pointer on clone if tagged").For there will possibly be more flags in the sk_user_data field,this patch also refactor sk_user_data flags code to be more genericto improve its maintainability.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50025 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix a memory leak in an error handling pathA bitmap_zalloc() must be balanced by a corresponding bitmap_free() in theerror handling path of afu_allocate_irqs().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-45918 Severity: Low CVSS3 score: 3.3

Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libncurses6 > 0-0 (version in image is 6.1-150000.5.30.1).

CVE-2023-51079 Severity: Low CVSS3 score: 3.3

Description: A long execution time can occur in the ParseTools.subCompileExpression method in MVEL 2.5.0.Final because of many Java class lookups. NOTE: the vendor disputes this because "the only thing that you could expect is that the parser will take a crazy amount of time to complete its task."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
mvel2 > 0-0 (version in image is 2.2.6.Final-150400.3.3.1).

CVE-2024-0340 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0727 Severity: Low CVSS3 score: 3.3

Description: Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSLto crash leading to a potential Denial of Service attackImpact summary: Applications loading files in the PKCS12 format from untrustedsources might terminate abruptly.A file in PKCS12 format can contain certificates and keys and may come from anuntrusted source. The PKCS12 specification allows certain fields to be NULL, butOpenSSL does not correctly check for this case. This can lead to a NULL pointerdereference that results in OpenSSL crashing. If an application processes PKCS12files from an untrusted source using the OpenSSL APIs then that application willbe vulnerable to this issue.OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()and PKCS12_newpass().We have also fixed a similar issue in SMIME_write_PKCS7(). However since thisfunction is related to writing data we do not consider it security significant.The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libopenssl1_1 > 0-0 (version in image is 1.1.1l-150400.7.84.1).

CVE-2024-26597 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: qualcomm: rmnet: fix global oob in rmnet_policyThe variable rmnet_link_ops assign a *bigger* maxtype which leads to aglobal out-of-bounds read when parsing the netlink attributes. See bugtrace below:==================================================================BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fdcf2072359Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 The buggy address belongs to the variable: rmnet_policy+0x30/0xe0The buggy address belongs to the physical page:page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243flags: 0x200000000001000(reserved|node=0|zone=2)raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9According to the comment of `nla_parse_nested_deprecated`, the maxtypeshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26835 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: set dormant flag on hook register failureWe need to set the dormant flag again if we fail to registerthe hooks.During memory pressure hook registration can fail and we end upwith a table marked as active but no registered hooks.On table/base chain deletion, nf_tables will attempt to unregisterthe hook again which yields a warn splat from the nftables core.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26837 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: switchdev: Skip MDB replays of deferred events on offloadBefore this change, generation of the list of MDB events to replaywould race against the creation of new group memberships, either fromthe IGMP/MLD snooping logic or from user configuration.While new memberships are immediately visible to walkers ofbr->mdb_list, the notification of their existence to switchdev eventsubscribers is deferred until a later point in time. So if a replaylist was generated during a time that overlapped with such a window,it would also contain a replay of the not-yet-delivered event.The driver would thus receive two copies of what the bridge internallyconsidered to be one single event. On destruction of the bridge, onlya single membership deletion event was therefore sent. As aconsequence of this, drivers which reference count memberships (atleast DSA), would be left with orphan groups in their hardwaredatabase when the bridge was destroyed.This is only an issue when replaying additions. While deletion eventsmay still be pending on the deferred queue, they will already havebeen removed from br->mdb_list, so no duplicates can be generated inthat scenario.To a user this meant that old group memberships, from a bridge inwhich a port was previously attached, could be reanimated (inhardware) when the port joined a new bridge, without the new bridge'sknowledge.For example, on an mv88e6xxx system, create a snooping bridge andimmediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$The two IPv6 groups remain in the hardware database because theport (x3) is notified of the host's membership twice: once via theoriginal event and once via a replay. Since only a single deletenotification is sent, the count remains at 1 when the bridge isdestroyed.Then add the same port (or another port belonging to the same hardwaredomain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1All multicast, including the two IPv6 groups from br0, should now beflooded, according to the policy of br1. But instead the oldmemberships are still active in the hardware database, causing theswitch to only forward traffic to those groups towards the CPU (port0).Eliminate the race in two steps:1. Grab the write-side lock of the MDB while generating the replay list.This prevents new memberships from showing up while we are generatingthe replay list. But it leaves the scenario in which a deferred eventwas already generated, but not delivered, before we grabbed thelock. Therefore:2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26839 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix a memleak in init_credit_returnWhen dma_alloc_coherent fails to allocate dd->cr_base[i].va,init_credit_return should deallocate dd->cr_base anddd->cr_base[i] that allocated before. Or those resourceswould be never freed and a memleak is triggered.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-34459 Severity: Low CVSS3 score: 3.3

Description: An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2024-36955 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()The documentation for device_get_named_child_node() mentions thisimportant point:"The caller is responsible for calling fwnode_handle_put() on thereturned fwnode pointer."Add fwnode_handle_put() to avoid a leaked reference.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40981 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: bypass empty buckets in batadv_purge_orig_ref()Many syzbot reports are pointing to soft lockups inbatadv_purge_orig_ref() [1]Root cause is unknown, but we can avoid spending too muchtime there and perhaps get more interesting reports.[1]watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]Modules linked in:irq event stamp: 6182794 hardirqs last enabled at (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024Workqueue: bat_events batadv_purge_origpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386sp : ffff800099007970x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Sending NMI from CPU 0 to CPUs 1:NMI backtrace for cpu 1CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103sp : ffff800093a17d30x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49895 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translationThis commit addresses a potential index out of bounds issue in the`cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30color management module. The issue could occur when the index 'i'exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds, the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53079 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/thp: fix deferred split unqueue naming and lockingRecent changes are putting more pressure on THP deferred split queues:under load revealing long-standing races, causing list_del corruptions,"Bad page state"s and worse (I keep BUGs in both of those, so usuallydon't get to see how badly they end up without). The relevant recentchanges being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin,improved swap allocation, and underused THP splitting.Before fixing locking: rename misleading folio_undo_large_rmappable(),which does not undo large_rmappable, to folio_unqueue_deferred_split(),which is what it does. But that and its out-of-line __callee are mminternals of very limited usability: add comment and WARN_ON_ONCEs tocheck usage; and return a bool to say if a deferred split was unqueued,which can then be used in WARN_ON_ONCEs around safety checks (sparingcallers the arcane conditionals in __folio_unqueue_deferred_split()).Just omit the folio_unqueue_deferred_split() from free_unref_folios(), allof whose callers now call it beforehand (and if any forget then bad_page()will tell) - except for its caller put_pages_list(), which itself nolonger has any callers (and will be deleted separately).Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0without checking and unqueueing a THP folio from deferred split list;which is unfortunate, since the split_queue_lock depends on the memcg(when memcg is enabled); so swapout has been unqueueing such THPs later,when freeing the folio, using the pgdat's lock instead: potentiallycorrupting the memcg's list. __remove_mapping() has frozen refcount to 0here, so no problem with calling folio_unqueue_deferred_split() beforeresetting memcg_data.That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred splitshrinker memcg aware"): which included a check on swapcache before addingto deferred queue, but no check on deferred queue before adding THP toswapcache. That worked fine with the usual sequence of events in reclaim(though there were a couple of rare ways in which a THP on deferred queuecould have been swapped out), but 6.12 commit dafff3f4c850 ("mm: splitunderused THPs") avoids splitting underused THPs in reclaim, which makesswapcache THPs on deferred queue commonplace.Keep the check on swapcache before adding to deferred queue? Yes: it isno longer essential, but preserves the existing behaviour, and is likelyto be a worthwhile optimization (vmstat showed much more traffic on thequeue under swapping load if the check was removed); update its comment.Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changingfolio->memcg_data without checking and unqueueing a THP folio from thedeferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only beused in a WARN_ON_ONCE to validate the fix, which must be done earlier:mem_cgroup_move_charge_pte_range() first try to split the THP (splittingof course unqueues), or skip it if that fails. Not ideal, but movingcharge has been requested, and khugepaged should repair the THP later:nobody wants new custom unqueueing code just for this deprecated case.The 87eaceb3faa5 commit did have the code to move from one deferred listto another (but was not conscious of its unsafety while refcount non-0);but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need caredeferred split queue in memcg charge move path"), which argued that theexistence of a PMD mapping guarantees that the THP cannot be on a deferredlist. As above, false in rare cases, and now commonly false.Backport to 6.11 should be straightforward. Earlier backports must takecare that other _deferred_list fixes and dependencies are included. Thereis not a strong case for backports, but they can fix cornercases.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56531 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56532 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: us122l: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.The loop of us122l->mmap_count check is dropped as well. The check isuseless for the asynchronous operation with *_when_closed().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56533 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usx2y: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56572 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()The buffer in the loop should be released under the exception path,otherwise there may be a memory leak here.To mitigate this, free the buffer when allegro_alloc_buffer fails.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56643 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix memory leak in dccp_feat_change_recvIf dccp_feat_push_confirm() fails after new value for SP feature was acceptedwithout reconciliation ('entry == NULL' branch), memory allocated for that valuewith dccp_feat_clone_sp_val() is never freed.Here is the kmemleak stack for this:unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1Clean up the allocated memory in case of dccp_feat_push_confirm() failureand bail out with an error reset code.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56741 Severity: Low CVSS3 score: 3.3

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57872 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()This will ensure that the scsi host is cleaned up properly usingscsi_host_dev_release(). Otherwise, it may lead to memory leaks.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57874 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRLCurrently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'variable, and a SETREGSET call with a length of zero will leave thisuninitialized. Consequently tagged_addr_ctrl_set() will consume anarbitrary value, potentially leaking up to 64 bits of memory from thekernel stack. The read is limited to a specific slot on the stack, andthe issue does not provide a write mechanism.As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero andrejects other values, a partial SETREGSET attempt will randomly succeedor fail depending on the value of the uninitialized value, and theexposure is significantly limited.Fix this by initializing the temporary value before copying the regsetfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existingvalue of the tagged address ctrl will be retained.The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in theuser_aarch64_view used by a native AArch64 task to manipulate anothernative AArch64 task. As get_tagged_addr_ctrl() only returns an errorvalue when called for a compat task, tagged_addr_ctrl_get() andtagged_addr_ctrl_set() should never observe an error value fromget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate thatsuch an error would be unexpected, and error handlnig is not missing ineither case.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57907 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: rockchip_saradc: fix information leak in triggered bufferThe 'data' local struct is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58001 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21656 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occurscsi_execute_cmd() function can return both negative (linux codes) andpositive (scsi_cmnd result field) error codes.Currently the driver just passes error codes of scsi_execute_cmd() tohwmon core, which is incorrect because hwmon only checks for negativeerror codes. This leads to hwmon reporting uninitialized data touserspace in case of SCSI errors (for example if the disk drive wasdisconnected).This patch checks scsi_execute_cmd() output and returns -EIO if it'serror code is positive.[groeck: Avoid inline variable declaration for portability]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21697 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21749 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: lock the socket in rose_bind()syzbot reported a soft lockup in rose_loopback_timer(),with a repro calling bind() from multiple threads.rose_bind() must lock the socket to avoid this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-2588 Severity: Low CVSS3 score: 3.3

Description: A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
augeas > 0-0 (version in image is 1.12.0-150400.3.8.1).

CVE-2025-37998 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: Fix unsafe attribute parsing in output_userspace()This patch replaces the manual Netlink attribute iteration inoutput_userspace() with nla_for_each_nested(), which ensures that onlywell-formed attributes are processed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38009 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: disable napi on driver removalA warning on driver removal started occurring after commit 9dd05df8403b("net: warn if NAPI instance wasn't shut down"). Disable tx napi beforedeleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7eTested with mt7921e but the same pattern can be actually applied to othermt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabledin their *_dma_init() functions and only toggled off and on again insidetheir suspend/resume/reset paths. So it should be okay to disable txnapi in such a generic way.Found by Linux Verification Center (linuxtesting.org).

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38384 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: spinand: fix memory leak of ECC engine confMemory allocated for the ECC engine conf is not released during spinandcleanup. Below kmemleak trace is seen for this memory leak:unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160Fix the leak by calling nanddev_ecc_engine_cleanup() insidespinand_cleanup().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38409 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix another leak in the submit error pathput_unused_fd() doesn't free the installed file, if we've already donefd_install(). So we need to also free the sync_file.Patchwork: https://patchwork.freedesktop.org/patch/653583/

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38439 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()with the proper length instead of 0. This bug triggers this warningon a system with IOMMU enabled:WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170RIP: 0010:__iommu_dma_unmap+0x159/0x170Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00RSP: 0018:ff22d31181150c88 EFLAGS: 00010206RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0PKRU: 55555554Call Trace:? show_regs+0x6d/0x80? __warn+0x89/0x160? __iommu_dma_unmap+0x159/0x170? report_bug+0x17e/0x1b0? handle_bug+0x46/0x90? exc_invalid_op+0x18/0x80? asm_exc_invalid_op+0x1b/0x20? __iommu_dma_unmap+0x159/0x170? __iommu_dma_unmap+0xb3/0x170iommu_dma_unmap_page+0x4f/0x100dma_unmap_page_attrs+0x52/0x220? srso_alias_return_thunk+0x5/0xfbef5? xdp_return_frame+0x2e/0xd0bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]bnxt_poll+0xd3/0x1e0 [bnxt_en]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38481 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold the array of `struct comedi_insn`, getting the length from the`n_insns` member of the `struct comedi_insnlist` supplied by the user.The allocation will fail with a WARNING and a stack dump if it is toolarge.Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`value is unreasonable.Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38565 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Exit early on perf_mmap() failWhen perf_mmap() fails to allocate a buffer, it still invokes theevent_mapped() callback of the related event. On X86 this might increasethe perf_rdpmc_allowed reference counter. But nothing undoes this asperf_mmap_close() is never called in this case, which causes anotherreference count leak.Return early on failure to prevent that.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38623 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Fix surprise plug detection and recoveryThe existing PowerNV hotplug code did not handle surprise plug eventscorrectly, leading to a complete failure of the hotplug system after deviceremoval and a required reboot to detect new devices.This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot.Issue the appropriate unfreeze and rescan commands on hotplug events,and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.[bhelgaas: tidy comments]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8224 Severity: Low CVSS3 score: 3.3

Description: A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-8225 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-8732 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
gettext-runtime > 0-0 (version in image is 0.20.2-1.43).

CVE-2025-15224 Severity: Moderate CVSS3 score: 3.1

Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2020-12965 Severity: Low CVSS3 score: 2.9

Description: When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-32415 Severity: Low CVSS3 score: 2.9

Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2024-42097 Severity: Moderate CVSS3 score: 2.8

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: emux: improve patch ioctl data validationIn load_data(), make the validation of and skipping over the main infoblock match that in load_guspatch().In load_guspatch(), add checking that the specified patch length matchesthe actually supplied data, like load_data() already did.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-5917 Severity: Moderate CVSS3 score: 2.8

Description: A vulnerability has been identified in the libarchive library. This flaw involves an 'off-by-one' miscalculation when handling prefixes and suffixes for file names. This can lead to a 1-byte write overflow. While seemingly small, such an overflow can corrupt adjacent memory, leading to unpredictable program behavior, crashes, or in specific circumstances, could be leveraged as a building block for more sophisticated exploitation. This bug affects libarchive versions prior to 3.8.0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
libarchive13 > 0-0 (version in image is 3.5.1-150400.3.21.1).

CVE-2023-48233 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2023-48234 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2023-48235 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause anoverflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2023-48236 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values largerthan MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2023-48237 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

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

CVE-2025-1215 Severity: Low CVSS3 score: 2.8

Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-30258 Severity: Low CVSS3 score: 2.7

Description: In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.1).

CVE-2024-35938 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: decrease MHI channel buffer length to 8KBCurrently buf_len field of ath11k_mhi_config_qca6390 is assignedwith 0, making MHI use a default size, 64KB, to allocate channelbuffers. This is likely to fail in some scenarios where systemmemory is highly fragmented and memory compaction or reclaim isnot allowed.There is a fail report which is caused by it:kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfcebWorkqueue: events_unbound async_run_entry_fnCall Trace: dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e] ? srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec] ? srso_alias_return_thunk+0x5/0xfbef5 dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 process_one_work+0x168/0x330 worker_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Actually those buffers are used only by QMI target -> host communication.And for WCN6855 and QCA6390, the largest packet size for that is lessthan 6KB. So change buf_len field to 8KB, which results in order 1allocation if page size is 4KB. In this way, we can at least save somememory, and as well as decrease the possibility of allocation failurein those scenarios.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38596 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races in unix_release_sock/unix_stream_sendmsgA data-race condition has been identified in af_unix. In one data path,the write function unix_release_sock() atomically writes tosk->sk_shutdown using WRITE_ONCE. However, on the reader side,unix_stream_sendmsg() does not read it atomically. Consequently, thisissue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")addressed a comparable issue in the past regarding sk->sk_shutdown.However, it overlooked resolving this particular data path.This patch only offending unix_stream_sendmsg() function, since theother reads seem to be protected by unix_state_lock() as discussed in

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46681 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:pktgen: use cpus_read_lock() in pg_net_init()I have seen the WARN_ON(smp_processor_id() != cpu) firingin pktgen_thread_worker() during tests.We must use cpus_read_lock()/cpus_read_unlock()around the for_each_online_cpu(cpu) loop.While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47710 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:sock_map: Add a cond_resched() in sock_hash_free()Several syzbot soft lockup reports all have in common sock_hash_free()If a map with a large number of buckets is destroyed, we need to yieldthe cpu when needed.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56729 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: Initialize cfid->tcon before performing network opsAvoid leaking a tcon ref when a lease break races with opening thecached directory. Processing the leak break might take a reference tothe tcon in cached_dir_lease_break() and then fail to release the ref incached_dir_offload_close, since cfid->tcon is still NULL.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37805 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:sound/virtio: Fix cancel_sync warnings on uninitialized work_structsBetty reported hitting the following warning:[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182...[ 8.713282][ T221] Call trace:[ 8.713365][ T221] __flush_work+0x8d0/0x914[ 8.713468][ T221] __cancel_work_sync+0xac/0xfc[ 8.713570][ T221] cancel_work_sync+0x24/0x34[ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.714035][ T221] virtio_dev_probe+0x28c/0x390[ 8.714139][ T221] really_probe+0x1bc/0x4c8...It seems we're hitting the error path in virtsnd_probe(), whichtriggers a virtsnd_remove() which iterates over the substreamscalling cancel_work_sync() on the elapsed_period work_struct.Looking at the code, from earlier in:virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()We set snd->nsubstreams, allocate the snd->substreams, and ifwe then hit an error on the info allocation or something invirtsnd_ctl_query_info() fails, we will exit without havinginitialized the elapsed_period work_struct.When that error path unwinds we then call virtsnd_remove()which as long as the substreams array is allocated, will iteratethrough calling cancel_work_sync() on the uninitialized workstruct hitting this warning.Takashi Iwai suggested this fix, which initializes the substreamsstructure right after allocation, so that if we hit the errorpaths we avoid trying to cleanup uninitialized data.Note: I have not yet managed to reproduce the issue myself, sothis patch has had limited testing.Feedback or thoughts would be appreciated!

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37857 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: st: Fix array overflow in st_setup()Change the array size to follow parms size instead of a fixed value.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49614 Severity: Low CVSS3 score: 2.5

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52746 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() int type = nla_type(nla); if (type > XFRMA_MAX) { return -EOPNOTSUPP; }@type is then used as an array index and can be usedas a Spectre v1 gadget. if (nla_len(nla) < compat_policy[type].len) {array_index_nospec() can be used to prevent leakingcontent of kernel memory to malicious users.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41007 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: avoid too many retransmit packetsIf a TCP socket is using TCP_USER_TIMEOUT, and the other peerretracted its window to zero, tcp_retransmit_timer() canretransmit a packet every two jiffies (2 ms for HZ=1000),for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.The fix is to make sure tcp_rtx_probe0_timed_out() takesicsk->icsk_user_timeout into account.Before blamed commit, the socket would not timeout aftericsk->icsk_user_timeout, but would use standard exponentialbackoff for the retransmits.Also worth noting that before commit e89688e3e978 ("net: tcp:fix unexcepted socket die when snd_wnd is 0"), the issuewould last 2 minutes instead of 4.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47660 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: clear PARENT_WATCHED flags lazilyIn some setups directories can have many (usually negative) dentries.Hence __fsnotify_update_child_dentry_flags() function can take asignificant amount of time. Since the bulk of this function happensunder inode->i_lock this causes a significant contention on the lockwhen we remove the watch from the directory as the__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()races with __fsnotify_update_child_dentry_flags() calls from__fsnotify_parent() happening on children. This can lead upto softlockupreports reported by users.Fix the problem by calling fsnotify_update_children_dentry_flags() toset PARENT_WATCHED flags only when parent starts watching children.When parent stops watching children, clear false positive PARENT_WATCHEDflags lazily in __fsnotify_parent() for each accessed child.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56644 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/ipv6: release expired exception dst cached in socketDst objects get leaked in ip6_negative_advice() when this function isexecuted for an expired IPv6 route located in the exception table. Thereare several conditions that must be fulfilled for the leak to occur:* an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created* a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions* after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dstWhen TCP executes ip6_negative_advice() for an exception dst that hasexpired and if no other socket holds a reference to the exception dst, therefcount of the exception dst is 2, which corresponds to the incrementmade by dst_init() and the increment made by the TCP socket for which theconnection is timing out. The refcount made by the socket is neverreleased. The refcount of the dst is decremented in sk_dst_reset() butthat decrement is counteracted by a dst_hold() intentionally placed justbefore the sk_dst_reset() in ip6_negative_advice(). Afterip6_negative_advice() has finished, there is no other object tied to thedst. The socket lost its reference stored in sk_dst_cache and the dst isno longer in the exception table. The exception dst becomes a leakedobject.As a result of this dst leak, an unbalanced refcount is reported for theloopback device of a net namespace being destroyed under kernels that donot contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):unregister_netdevice: waiting for lo to become free. Usage count = 2Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). Thepatch that introduced the dst_hold() in ip6_negative_advice() was92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22merely refactored the code with regards to the dst refcount so the issuewas present even before 92f1655aa2b22. The bug was introduced in54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actuallyexpired.") where the expired cached route is deleted and the sk_dst_cachemember of the socket is set to NULL by calling dst_negative_advice() butthe refcount belonging to the socket is left unbalanced.The IPv4 version - ipv4_negative_advice() - is not affected by this bug.When the TCP connection times out ipv4_negative_advice() merely resets thesk_dst_cache of the socket while decrementing the refcount of theexception dst.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56747 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1352 Severity: Low CVSS3 score: 2.5

Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
elfutils > 0-0 (version in image is 0.185-150400.5.3.1).

CVE-2025-1376 Severity: Low CVSS3 score: 2.5

Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
elfutils > 0-0 (version in image is 0.185-150400.5.3.1).

CVE-2025-21683 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix bpf_sk_select_reuseport() memory leakAs pointed out in the original comment, lookup in sockmap can return a TCPESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPFset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cbdoes not imply a non-refcounted socket.Drop sk's reference in both error paths.unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22021 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: socket: Lookup orig tuple for IPv6 SNATnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets torestore the original 5-tuple in case of SNAT, to be able to find theright socket (if any). Then socket_match() can correctly check whetherthe socket was transparent.However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks thisconntrack lookup, making xt_socket fail to match on the socket when thepacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, aspods' addresses are in the fd00::/8 ULA subnet and need to be replacedwith the node's external address. Cilium leverages Envoy to enforce L7policies, and Envoy uses transparent sockets. Cilium inserts an iptablesprerouting rule that matches on `-m socket --transparent` and redirectsthe packets to localhost, but it fails to match SNATed IPv6 packets dueto that missing conntrack lookup.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38058 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock... or we risk stealing final mntput from sync umount - raising mnt_countafter umount(2) has verified that victim is not busy, but before ithas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't seethat it's safe to quietly undo mnt_count increment and leaves droppingthe reference to caller, where it'll be a full-blown mntput().Check under mount_lock is needed; leaving the current one done beforetaking that makes no sense - it's nowhere near common enough to botherwith.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38103 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()Update struct hid_descriptor to better reflect the mandatory andoptional parts of the HID Descriptor as per USB HID 1.11 specification.Note: the kernel currently does not parse any optional HID classdescriptors, only the mandatory report descriptor.Update all references to member element desc[0] to rpt_desc.Add test to verify bLength and bNumDescriptors values are valid.Replace the for loop with direct access to the mandatory HID classdescriptor member for the report descriptor. This eliminates thepossibility of getting an out-of-bounds fault.Add a warning message if the HID descriptor contains any unsupportedoptional HID class descriptors.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22116 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: check error for register_netdev() on initCurrent init logic ignores the error code from register_netdev(),which will cause WARN_ON() on attempt to unregister it, if there was one,and there is no info for the user that the creation of the netdev failed.WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10...[ 3707.563641] unregister_netdev+0x1c/0x30[ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf][ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf][ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf][ 3707.563739] idpf_remove+0xbf/0x780 [idpf][ 3707.563769] pci_device_remove+0xab/0x1e0[ 3707.563786] device_release_driver_internal+0x371/0x530[ 3707.563803] driver_detach+0xbf/0x180[ 3707.563816] bus_remove_driver+0x11b/0x2a0[ 3707.563829] pci_unregister_driver+0x2a/0x250Introduce an error check and log the vport number and error code.On removal make sure to check VPORT_REG_NETDEV flag prior to callingunregister and free on the netdev.Add local variables for idx, vport_config and netdev for readability.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37905 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Balance device refcount when destroying devicesUsing device_find_child() to lookup the proper SCMI device to destroycauses an unbalance in device refcount, since device_find_child() calls animplicit get_device(): this, in turns, inhibits the call of the providedrelease methods upon devices destruction.As a consequence, one of the structures that is not freed properly upondestruction is the internal struct device_private dev->p populated by thedrivers subsystem core.KMemleak detects this situation since loading/unloding some SCMI drivercauses related devices to be created/destroyed without calling anydevice_release method.unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0device_add+0x954/0x12d0:kmalloc_noprof at include/linux/slab.h:901(inlined by) kzalloc_noprof at include/linux/slab.h:1037(inlined by) device_private_init at drivers/base/core.c:3510(inlined by) device_add at drivers/base/core.c:3561Balance device refcount by issuing a put_device() on devices found viadevice_find_child().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37925 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: reject on-disk inodes of an unsupported typeSyzbot has reported the following BUG:kernel BUG at fs/inode.c:668!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014RIP: 0010:clear_inode+0x168/0x190Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7fRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlyingJFS inode of unknown type. According to JFS layout description fromhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to15 are reserved for future extensions and should not be encountered on a validfilesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38045 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix debug actions orderThe order of actions taken for debug was implemented incorrectly.Now we implemented the dump split and do the FW reset only in themiddle of the dump (rather than the FW killing itself on error.)As a result, some of the actions taken when applying the configwill now crash the device, so we need to fix the order.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48714 Severity: Low CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Use VM_MAP instead of VM_ALLOC for ringbufAfter commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pagesafter mapping"), non-VM_ALLOC mappings will be marked as accessiblein __get_vm_area_node() when KASAN is enabled. But now the flag forringbuf area is VM_ALLOC, so KASAN will complain out-of-bound accessafter vmap() returns. Because the ringbuf area is created by mappingallocated pages, so use VM_MAP instead.After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc userto [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37742 Severity: Moderate CVSS3 score: 1.9

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix uninit-value access of imap allocated in the diMount() functionsyzbot reports that hex_dump_to_buffer is using uninit-value:=====================================================BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156evict+0x723/0xd10 fs/inode.c:796iput_final fs/inode.c:1946 [inline]iput+0x97b/0xdb0 fs/inode.c:1972txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733kthread+0x6b9/0xef0 kernel/kthread.c:464ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Uninit was created at:slab_post_alloc_hook mm/slub.c:4121 [inline]slab_alloc_node mm/slub.c:4164 [inline]__kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320kmalloc_noprof include/linux/slab.h:901 [inline]diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636get_tree_bdev+0x37/0x50 fs/super.c:1659jfs_get_tree+0x34/0x40 fs/jfs/super.c:635vfs_get_tree+0xb1/0x5a0 fs/super.c:1814do_new_mount+0x71f/0x15e0 fs/namespace.c:3560path_mount+0x742/0x1f10 fs/namespace.c:3887do_mount fs/namespace.c:3900 [inline]__do_sys_mount fs/namespace.c:4111 [inline]__se_sys_mount+0x71f/0x800 fs/namespace.c:4088__x64_sys_mount+0xe4/0x150 fs/namespace.c:4088x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7f=====================================================The reason is that imap is not properly initialized after memoryallocation. It will cause the snprintf() function to write uninitializeddata into linebuf within hex_dump_to_buffer().Fix this by using kzalloc instead of kmalloc to clear its content at thebeginning in diMount().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47623 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fixmap: Fix VM debug warning on unmapUnmapping a fixmap entry is done by calling __set_fixmap()with FIXMAP_PAGE_CLEAR as flags.Today, powerpc __set_fixmap() calls map_kernel_page().map_kernel_page() is not happy when called a second timefor the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 NIP [c0017cd4] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Call Trace: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable) [e1011e30] [c0165fec] __set_fixmap+0x30/0x44 [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030Implement unmap_kernel_page() which clears an existing pte.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47640 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Fix early region not updated correctlyThe shadow's page table is not updated when PTE_RPN_SHIFT is 24and PAGE_SHIFT is 12. It not only causes false positives butalso false negative as shown the following text.Fix it by bringing the logic of kasan_early_shadow_page_entry here.1. False Positive:==================================================================BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50Write of size 16 at addr f57f3be0 by task swapper/0/1CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1Call Trace:[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0[c80d1cc0] [c03018a4] memset+0x34/0x90[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0[c80d1db0] [c2036580] init_sd+0xc4/0x1d0[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384[c80d1ef0] [c0004b14] kernel_init+0x24/0x170[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================2. False Negative (with KASAN tests):==================================================================Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan==================================================================After fix: ok 1 - kasan

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49081 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:highmem: fix checks in __kmap_local_sched_{in,out}When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} checkthat even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots areinitialized with 0 value, but the check is done with pte_none. 0 ptehowever does not necessarily mean that pte_none will return true. e.g.on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7fFix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49567 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26907 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41041 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().syzkaller triggered the warning [0] in udp_v4_early_demux().In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcountof the looked-up sk and use sock_pfree() as skb->destructor, so we checkSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU graceperiod.Currently, SOCK_RCU_FREE is flagged for a bound socket after being putinto the hash table. Moreover, the SOCK_RCU_FREE check is done too earlyin udp_v[46]_early_demux() and sk_lookup(), so there could be a small racewindow: CPU1 CPU2 ---- ---- udp_v4_early_demux() udp_lib_get_port() | |- hlist_add_head_rcu() |- sk = __udp4_lib_demux_lookup() | |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk)); `- sock_set_flag(sk, SOCK_RCU_FREE)We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:set SOCK_RCU_FREE before inserting socket into hashtable").Let's apply the same fix for UDP.[0]:WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599Modules linked in:CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92cRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004eFS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600PKRU: 55555554Call Trace: ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738 netif_receive_skb_internal net/core/dev.c:5824 [inline] netif_receive_skb+0x271/0x300 net/core/dev.c:5884 tun_rx_batched drivers/net/tun.c:1549 [inline] tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x76f/0x8d0 fs/read_write.c:590 ksys_write+0xbf/0x190 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x41/0x50 fs/read_write.c:652 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fc44a68bc1fCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1fR---truncated---

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44983 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: validate vlan headerEnsure there is sufficient room to access the protocol field of theVLAN header, validate it once before the flowtable lookup.=====================================================BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5440 [inline]

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46758 Severity: Moderate CVSS3 score: 0.0

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47693 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:IB/core: Fix ib_cache_setup_one error flow cleanupWhen ib_cache_update return an error, we exit ib_cache_setup_oneinstantly with no proper cleanup, even though before this we hadalready successfully done gid_table_setup_one, that results inthe kernel WARN below.Do proper cleanup using gid_table_cleanup_one before returningthe err in order to fix the issue.WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0Modules linked in:CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:gid_table_release_one+0x181/0x1a0Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53196 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Don't retire aborted MMIO instructionReturning an abort to the guest for an unsupported MMIO access is adocumented feature of the KVM UAPI. Nevertheless, it's clear that thisplumbing has seen limited testing, since userspace can trivially cause aWARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The splat is complaining that KVM is advancing PC while an exception ispending, i.e. that KVM is retiring the MMIO instruction despite apending synchronous external abort. Womp womp.Fix the glaring UAPI bug by skipping over all the MMIO emulation incase there is a pending synchronous exception. Note that while userspaceis capable of pending an asynchronous exception (SError, IRQ, or FIQ),it is still safe to retire the MMIO instruction in this case as (1) theyare by definition asynchronous, and (2) KVM relies on hardware supportfor pending/delivering these exceptions instead of the software statemachine for advancing PC.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56781 Severity: Moderate CVSS3 score: 0.0

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57913 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Remove WARN_ON in functionfs_bindThis commit addresses an issue related to below kernel panic wherepanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ONin functionsfs_bind, which easily leads to the following scenarios.1.adb_write in adbd 2. UDC write via configfs ================= =====================->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register()->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function()->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE>The adb_open, adb_read, and adb_write operations are invoked from thedaemon, but trying to bind the function is a process that is invoked byUDC write through configfs, which opens up the possibility of a racecondition between the two paths. In this race scenario, the kernel panicoccurs due to the WARN_ON from functionfs_bind when panic_on_warn isenabled. This commit fixes the kernel panic by removing the unnecessaryWARN_ON.Kernel panic - not syncing: kernel: panic_on_warn set ...[ 14.542395] Call trace:[ 14.542464] ffs_func_bind+0x1c8/0x14a8[ 14.542468] usb_add_function+0xcc/0x1f0[ 14.542473] configfs_composite_bind+0x468/0x588[ 14.542478] gadget_bind_driver+0x108/0x27c[ 14.542483] really_probe+0x190/0x374[ 14.542488] __driver_probe_device+0xa0/0x12c[ 14.542492] driver_probe_device+0x3c/0x220[ 14.542498] __driver_attach+0x11c/0x1fc[ 14.542502] bus_for_each_dev+0x104/0x160[ 14.542506] driver_attach+0x24/0x34[ 14.542510] bus_add_driver+0x154/0x270[ 14.542514] driver_register+0x68/0x104[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144[ 14.542526] configfs_write_iter+0xf0/0x138

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-10148 Severity: Moderate CVSS3 score: None

Description: curl's websocket code did not update the 32 bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask thatpersisted and was used throughout the entire connection.A predictable mask pattern allows for a malicious server to induce trafficbetween the two communicating parties that could be interpreted by an involvedproxy (configured or transparent) as genuine, real, HTTP traffic with contentand thereby poison its cache. That cached poisoned content could then beserved to all users of that proxy.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-1149 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1178 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1181 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-20054 Severity: Moderate CVSS3 score: None

Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-20103 Severity: Moderate CVSS3 score: None

Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37835 Severity: Moderate CVSS3 score: None

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

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37911 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix out-of-bound memcpy() during ethtool -wWhen retrieving the FW coredump using ethtool, it can sometimes causememory corruption:BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]ethtool_get_dump_data+0xdc/0x1a0__dev_ethtool+0xa1e/0x1af0dev_ethtool+0xa8/0x170dev_ioctl+0x1b5/0x580sock_do_ioctl+0xab/0xf0sock_ioctl+0x1ce/0x2e0__x64_sys_ioctl+0x87/0xc0do_syscall_64+0x5c/0xf0entry_SYSCALL_64_after_hwframe+0x78/0x80...This happens when copying the coredump segment list inbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.The info->dest_buf buffer is allocated based on the number of coredumpsegments returned by the FW. The segment list is then DMA'ed bythe FW and the length of the DMA is returned by FW. The driver thencopies this DMA'ed segment list to info->dest_buf.In some cases, this DMA length may exceed the info->dest_buf lengthand cause the above BUG condition. Fix it by capping the copylength to not exceed the length of info->dest_buf. The extraDMA data contains no useful information.This code path is shared for the HWRM_DBG_COREDUMP_LIST and theHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is differentfor these 2 FW commands. To simplify the logic, we need to movethe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVEup, so that the new check to cap the copy length will work for bothcommands.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37930 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()Nouveau is mostly designed in a way that it's expected that fences onlyever get signaled through nouveau_fence_signal(). However, in at leastone other place, nouveau_fence_done(), can signal fences, too. If thathappens (race) a signaled fence remains in the pending list for a while,until it gets removed by nouveau_fence_update().Should nouveau_fence_context_kill() run in the meantime, this would bea bug because the function would attempt to set an error code on analready signaled fence.Have nouveau_fence_context_kill() check for a fence being signaled.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38037 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Annotate FDB data racesThe 'used' and 'updated' fields in the FDB entry structure can beaccessed concurrently by multiple threads, leading to reports such as[1]. Can be reproduced using [2].Suppress these reports by annotating these accesses usingREAD_ONCE() / WRITE_ONCE().[1]BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmitwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6fReported by Kernel Concurrency Sanitizer on:CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38039 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabledWhen attempting to enable MQPRIO while HTB offload is alreadyconfigured, the driver currently returns `-EINVAL` and triggers a`WARN_ON`, leading to an unnecessary call trace.Update the code to handle this case more gracefully by returning`-EOPNOTSUPP` instead, while also providing a helpful user message.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38043 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Set dma_mask for ffa devicesSet dma_mask for FFA devices, otherwise DMA allocation using the device pointerlead to following warning:WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38044 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:media: cx231xx: set device_caps for 417The video_device for the MPEG encoder did not set device_caps.Add this, otherwise the video device can't be registered (you get aWARN_ON instead).Not seen before since currently 417 support is disabled, but I foundthis while experimenting with it.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38324 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().As syzbot reported [0], mpls_route_input_rcu() can be calledfrom mpls_getroute(), where is under RTNL.net->mpls.platform_label is only updated under RTNL.Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() tosilence the splat.[0]:WARNING: suspicious RCU usage6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ----------------------------net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961stack backtrace:CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0a2818e969Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1148 Severity: Low CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1151 Severity: Low CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1152 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1153 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1180 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-1377 Severity: Low CVSS3 score: 0.0

Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
elfutils > 0-0 (version in image is 0.185-150400.5.3.1).

CVE-2025-38048 Severity: Low CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_ring: Fix data race by tagging event_triggered as racy for KCSANsyzbot reports a data-race when accessing the event_triggered, here is thesimplified stack when the issue occurred:==================================================================BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayedwrite to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline]read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline]value changed: 0x01 -> 0x00==================================================================When the data race occurs, the function virtqueue_enable_cb_delayed() setsevent_triggered to false, and virtqueue_disable_cb_split/packed() reads itas false due to the race condition. Since event_triggered is an unreliablehint used for optimization, this should only cause the driver temporarilysuggest that the device not send an interrupt notification when the eventindex is used.Fix this KCSAN reported data-race issue by explicitly tagging the access asdata_racy.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-24864 Severity: Not set CVSS3 score: 0.0

Description: A race condition was found in the Linux kernel's media/dvb-core in dvbdmx_write() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Packages affected:

SUSE-Manager-Server-release == 4.3 (version in image is 4.3-150400.56.5.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE scan

Summary of CVEs affecting the image: