-
Description: REST client for Ruby (aka rest-client) before 1.8.0 allows remote attackers to conduct session fixation attacks or obtain sensitive cookie information by leveraging passage of cookies set in a response to a redirect.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python-requests > 0-0 (version in image is 2.24.0-8.23.1).
-
Description: Salt before 2015.8.11 allows deleted minions to read or write to minions with the same id, related to caching.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- salt > 0-0 (version in image is 3000-74.1).
-
Description: A flaw in the IBM J9 VM class verifier allows untrusted code to disable the security manager and elevate its privileges. IBM X-Force ID: 126873.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. This flaw allows an attacker to execute arbitrary code on the system by abusing the python/object/new constructor. This flaw is due to an incomplete fix for CVE-2020-1747.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python3-PyYAML < 5.3.1-28.6.1 (version in image is 5.3.1-3.14.1).
-
Description: BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability.The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: The Salt-SSH pre-flight option copies the script to the target at a predictable path, which allows an attacker to force Salt-SSH to run their script. If an attacker has access to the target VM and knows the path to the pre-flight script before it runs they can ensure Salt-SSH runs their script with the privileges of the user running Salt-SSH. Do not make the copy path on the target predictable and ensure we check return codes of the scp command if the copy fails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- salt > 0-0 (version in image is 3000-74.1).
-
Description: The Fiddle::Handle implementation in ext/fiddle/handle.c in Ruby before 2.0.0-p648, 2.1 before 2.1.8, and 2.2 before 2.2.4, as distributed in Apple OS X before 10.11.4 and other products, mishandles tainting, which allows context-dependent attackers to execute arbitrary code or cause a denial of service (application crash) via a crafted string, related to the DL module and the libffi library. NOTE: this vulnerability exists because of a CVE-2009-5147 regression.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ruby > 0-0 (version in image is 2.1-1.6).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: JavaFX). The supported version that is affected is Java SE: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. 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 does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hisilicon: Fix potential use-after-free in hisi_femac_rx()The skb is delivered to napi_gro_receive() which may free it, aftercalling this, dereferencing skb may trigger use-after-free.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ruby2.1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In libzypp before 20170803 it was possible to add unsigned YUM repositories without warning to the user that could lead to man in the middle or malicious servers to inject malicious RPM packages into a users system.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- zypper > 0-0 (version in image is 1.13.67-21.64.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vivid: fix compose size exceed boundarysyzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10[...] Call Trace: ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 This is because we forget to check boundary after adjust compose->heightint V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problemfor this case.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid use-after-free in ip6_fragment()Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.It seems to not be always true, at least for UDP stack.syzbot reported:BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [inline] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fde3588c0d9Code: 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:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000aRBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 Allocated by task 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline] rt6_make_pcpu_route net/ipv6/route.c:1417 [inline] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [inline] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec n---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/khugepaged: invoke MMU notifiers in shmem/file collapse pathsAny codepath that zaps page table entries must invoke MMU notifiers toensure that secondary MMUs (like KVM) don't keep accessing pages whicharen't mapped anymore. Secondary MMUs don't hold their own references topages that are mirrored over, so failing to notify them can lead to pageuse-after-free.I'm marking this as addressing an issue introduced in commit f3f0e1d2150b("khugepaged: add support of collapse for tmpfs/shmem pages"), but most ofthe security impact of this only came in commit 27e1f8273113 ("khugepaged:enable collapse pmd for pte-mapped THP"), which actually omitted flushesfor the removal of present PTEs, not just for the removal of empty pagetables.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: Fix potential use-after-freeThe skb is delivered to netif_rx() which may free it, after calling this,dereferencing skb may trigger use-after-free.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZEI expect that the hardware will have limited this to 16, but just incase it hasn't, check for this corner case.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix mpol_new leak in shared_policy_replaceIf mpol_new is allocated but not used in restart loop, mpol_new will befreed via mpol_put before returning to the caller. But refcnt is notinitialized yet, so mpol_put could not do the right things and mightleak the unused mpol_new. This would happen if mempolicy was updated onthe shared shmem file while the sp->lock has been dropped during thememory allocation.This issue could be triggered easily with the below code snippet ifthere are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: m_can: m_can_tx_handler(): fix use after free of skbcan_put_echo_skb() will clone skb then free the skb. Move thecan_put_echo_skb() for the m_can version 3.0.x directly before thestart of the xmit in hardware, similar to the 3.1.x branch.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - add param check for RSAReject requests with a source buffer that is bigger than the size of thekey. This is to prevent a possible integer underflow that might happenwhen copying the source scatterlist into a linear buffer.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - add param check for DHReject requests with a source buffer that is bigger than the size of thekey. This is to prevent a possible integer underflow that might happenwhen copying the source scatterlist into a linear buffer.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: handle backlogging of crypto requestsSince we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on ourrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, whenthe cryptd queue for AESNI is full (easy to trigger with anartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueuedto the backlog but still processed. In that case, the async callbackwill also be called twice: first with err == -EINPROGRESS, which itseems we can just ignore, then with err == 0.Compared to Sabrina's original patch this version uses the newtls_*crypt_async_wait() helpers and converts the EBUSY toEINPROGRESS to avoid having to modify all the error handlingpaths. The handling is identical.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check link_index before accessing dc->links[][WHY & HOW]dc->links[] has max size of MAX_LINKS and NULL is return when trying toaccess with out-of-bound index.This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links[Why]Coverity report OVERRUN warning. There areonly max_links elements within dc->links. linkcount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.[How]Make sure link count less than max_links.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: sysfs: validate return type of _STR methodOnly buffer objects are valid return values of _STR.If something else is returned description_show() will access invalidmemory.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in async decryptionDoing an async decryption (large read) crashes with aslab-use-after-free way down in the crypto API.Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]This is because TFM is being used in parallel.Fix this by allocating a new AEAD TFM for async decryption, but keepthe existing one for synchronous READ cases (similar to what is donein smb3_calc_signature()).Also remove the calls to aead_request_set_callback() andcrypto_wait_req() since it's always going to be a synchronous operation.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: io_edgeport: fix use after free in debug printkThe "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb)is a use after free of the "urb" pointer. Store the "dev" pointer at thestart of the function to avoid this issue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOTIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumedto be either root or ingress. This assumption is bogus since it's validto create egress qdiscs with major handle ffff:Budimir Markovic found that for qdiscs like DRR that maintain an activeclass list, it will cause a UAF with a dangling class pointer.In 066a3b5b2346, the concern was to avoid iterating over the ingressqdisc since its parent is itself. The proper fix is to stop when parentTC_H_ROOT is reached because the only way to retrieve ingress is when ahierarchy which does not contain a ffff: major handle call intoqdisc_lookup with TC_H_MAJ(TC_H_ROOT).In the scenario where major ffff: is an egress qdisc in any of the treelevels, the updates will also propagate to TC_H_ROOT, which then theiteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-jpeg: prevent buffer overflowsThe current logic allows word to be less than 2. If this happens,there will be buffer overflows, as reported by smatch. Add extrachecks to prevent it.While here, remove an unused word = 0 assignment.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_formatThis can lead to out of bounds writes since frames of this type were nottaken into account when calculating the size of the frames buffer inuvc_parse_streaming.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent a potential integer overflowIf the tag length is >= U32_MAX - 3 then the "length + 4" additioncan result in an integer overflow. Address this by splitting thedecoding into several steps so that decode_cb_compound4res() doesnot have to perform arithmetic on the unsafe length value.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ...Since this bug has been confirmed to be caused by insufficient verificationof conn_rsp_epid, I think it would be appropriate to add a range check forconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp's timer handler function causes problems.To fix this problem, let's hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the 'NextCapability Offset' field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: 6fire: Release resources at card releaseThe current 6fire code tries to release the resources right after thecall of usb6fire_chip_abort(). But at this moment, the card objectmight be still in use (as we're calling snd_card_free_when_closed()).For avoid potential UAFs, move the release of resources to the card'sprivate_free instead of the manual call of usb6fire_chip_destroy() atthe USB disconnect callback.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet6: do not leave a dangling sk pointer in inet6_create()sock_init_data() attaches the allocated sk pointer to the provided sockobject. If inet6_create() fails later, the sk object is released, but thesock object retains the dangling sk pointer, which may cause use-after-freelater.Clear the sock sk pointer on error.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet: do not leave a dangling sk pointer in inet_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If inet_create() fails later, the sk object is freed, but thesock object retains the dangling pointer, which may create use-after-freelater.Clear the sk pointer in the sock object on error.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()bt_sock_alloc() allocates the sk object and attaches it to the providedsock object. On error l2cap_sock_alloc() frees the sk object, but thedangling pointer is still attached to the sock object, which may createuse-after-free in other code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix LED ID check in led_tg_check()Syzbot has reported the following BUG detected by KASAN:BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70Read of size 1 at addr ffff8881022da0c8 by task repro/5879...Call Trace: dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... Since an invalid (without '\0' byte at all) byte sequence may be passedfrom userspace, add an extra check to ensure that such a sequence isrejected as possible ID and so never passed to 'kstrdup()' and further.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: defer final 'struct net' free in netns dismantleIlya reported a slab-use-after-free in dst_destroy [1]Issue is in xfrm6_net_init() and xfrm4_net_init() :They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.But net structure might be freed before all the dst callbacks arecalled. So when dst_destroy() calls later :if (dst->ops->destroy) dst->ops->destroy(dst);dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.See a relevant issue fixed in :ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")A fix is to queue the 'struct net' to be freed after oneanother cleanup_net() round (and existing rcu_barrier())[1]BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0Dec 03 05:46:18 kernel:CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:124)print_address_description.constprop.0 (mm/kasan/report.c:378)? dst_destroy (net/core/dst.c:112)print_report (mm/kasan/report.c:489)? dst_destroy (net/core/dst.c:112)? kasan_addr_to_slab (mm/kasan/common.c:37)kasan_report (mm/kasan/report.c:603)? dst_destroy (net/core/dst.c:112)? rcu_do_batch (kernel/rcu/tree.c:2567)dst_destroy (net/core/dst.c:112)rcu_do_batch (kernel/rcu/tree.c:2567)? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)rcu_core (kernel/rcu/tree.c:2825)handle_softirqs (kernel/softirq.c:554)__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)irq_exit_rcu (kernel/softirq.c:651)sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835dR10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)? cpuidle_idle_call (kernel/sched/idle.c:186)default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)cpuidle_idle_call (kernel/sched/idle.c:186)? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)do_idle (kernel/sched/idle.c:326)cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452)common_startup_64 (arch/x86/kernel/head_64.S:414) Dec 03 05:46:18 kernel:Allocated by task 12184:kasan_save_stack (mm/kasan/common.c:48)kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)create_new_namespaces---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: don't allow 1 packet limitThe current implementation does not work correctly with a limit of1. iproute2 actually checks for this and this patch adds the check inkernel as well.This fixes the following syzkaller reported crash:UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6index 65535 is out of range for type 'struct sfq_head[128]'CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcbRIP: 0033:0x7fe5e7b52479Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270The crash can be also be reproduced with the following (with a tcrecompiled to allow for sfq limits of 1):tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1ifconfig dummy0 upping -I dummy0 -f -c2 -W0.1 8.8.8.8sleep 1Scenario that triggers the crash:* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1* TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later.* the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL.At this point, assuming no more packets are queued, when sch_dequeueruns again it will decrement the qlen for the current empty slotcausing an underflow and the subsequent out of bounds access.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN()instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access.Compile tested only.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pfifo_tail_enqueue: Drop new packet when sch->limit == 0Expected behaviour:In case we reach scheduler's limit, pfifo_tail_enqueue() will drop apacket in scheduler's queue and decrease scheduler's qlen by one.Then, pfifo_tail_enqueue() enqueue new packet and increasescheduler's qlen by one. Finally, pfifo_tail_enqueue() return`NET_XMIT_CN` status code.Weird behaviour:In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on ascheduler that has no packet, the 'drop a packet' step will do nothing.This means the scheduler's qlen still has value equal 0.Then, we continue to enqueue new packet and increase scheduler's qlen byone. In summary, we can leverage pfifo_tail_enqueue() to increase qlen byone and return `NET_XMIT_CN` status code.The problem is:Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1.Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem.This violate the design where parent's qlen should equal to the sum of its childrens'qlen.Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vrf: use RCU protection in l3mdev_l3_out()l3mdev_l3_out() can be called without RCU being held:raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()Add rcu_read_lock() / rcu_read_unlock() pair to avoida potential UAF.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: If a compromised content process sent an unexpected number of WebAuthN Extensions in a Register command to the parent process, an out of bounds write would have occurred leading to memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Mozilla developers and community members Randell Jesup, Sebastian Hengst, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 98. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 99.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Mozilla developers and community members Nika Layzell, Andrew McCreight, Gabriele Svelto, and the Mozilla Fuzzing Team reported memory safety bugs present in Thunderbird 91.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: An attacker could have abused XSLT error handling to associate attacker-controlled content with another origin which was displayed in the address bar. This could have been used to fool the user into submitting data intended for the spoofed origin. This vulnerability affects Thunderbird < 102.2, Thunderbird < 91.13, Firefox ESR < 91.13, Firefox ESR < 102.2, and Firefox < 104.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: A cross-origin iframe referencing an XSLT document would inherit the parent domain's permissions (such as microphone or camera access). This vulnerability affects Thunderbird < 102.2, Thunderbird < 91.13, Firefox ESR < 91.13, Firefox ESR < 102.2, and Firefox < 104.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: A data race could occur in the PK11_ChangePW function, potentially leading to a use-after-free vulnerability. In Firefox, this lock protected the data when a user changed their master password. This vulnerability affects Firefox ESR < 102.2 and Thunderbird < 102.2.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Mozilla developer Nika Layzell and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 103 and Firefox ESR 102.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR < 102.2, Thunderbird < 102.2, and Firefox < 104.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Members the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 103, Firefox ESR 102.1, and Firefox ESR 91.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Thunderbird < 102.2, Thunderbird < 91.13, Firefox ESR < 91.13, Firefox ESR < 102.2, and Firefox < 104.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: check skb is non-NULL in tcp_rto_delta_us()We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generickernel that are running ceph and recently hit a null ptr dereference intcp_rearm_rto(). Initially hitting it from the TLP path, but then later we alsosaw it getting hit from the RACK case as well. Here are examples of the oopsmessages we saw in each of those cases:Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel modeJul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present pageJul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTIJul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-UbuntuJul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554Jul 26 15:05:02 rx [11061395.916786] Call Trace:Jul 26 15:05:02 rx [11061395.919488]Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1fJul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
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 >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent > 0-0 (version in image is 20250506.01-1.53.1).
-
Description: crypto/rsa/rsa_ameth.c in OpenSSL 1.0.1 before 1.0.1q and 1.0.2 before 1.0.2e allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an RSA PSS ASN.1 signature that lacks a mask generation function parameter.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash. For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305; users should upgrade to 1.1.0d. For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: The log_config_command function in ntp_parser.y in ntpd in NTP before 4.2.7p42 allows remote attackers to cause a denial of service (ntpd crash) via crafted logconfig commands.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ntp > 0-0 (version in image is 4.2.8p17-106.7.1).
-
Description: ntp_openssl.m4 in ntpd in NTP before 4.2.7p112 allows remote attackers to cause a denial of service (segmentation fault) via a crafted statistics or filegen configuration command that is not enabled during compilation.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ntp > 0-0 (version in image is 4.2.8p17-106.7.1).
-
Description: `Bundler` is a package for managing application dependencies in Ruby. In `bundler` versions before 2.2.33, when working with untrusted and apparently harmless `Gemfile`'s, it is not expected that they lead to execution of external code, unless that's explicit in the ruby code inside the `Gemfile` itself. However, if the `Gemfile` includes `gem` entries that use the `git` option with invalid, but seemingly harmless, values with a leading dash, this can be false. To handle dependencies that come from a Git repository instead of a registry, Bundler uses various commands, such as `git clone`. These commands are being constructed using user input (e.g. the repository URL). When building the commands, Bundler versions before 2.2.33 correctly avoid Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash (`-`) and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables. Since this value comes from the `Gemfile` file, it can contain any character, including a leading dash.To exploit this vulnerability, an attacker has to craft a directory containing a `Gemfile` file that declares a dependency that is located in a Git repository. This dependency has to have a Git URL in the form of `-u./payload`. This URL will be used to construct a Git clone command but will be interpreted as the upload-pack argument. Then this directory needs to be shared with the victim, who then needs to run a command that evaluates the Gemfile, such as `bundle lock`, inside.This vulnerability can lead to Arbitrary Code Execution, which could potentially lead to the takeover of the system. However, the exploitability is very low, because it requires a lot of user interaction. Bundler 2.2.33 has patched this problem by inserting `--` as an argument before any positional arguments to those Git commands that were affected by this issue. Regardless of whether users can upgrade or not, they should review any untrustred `Gemfile`'s before running any `bundler` commands that may read them, since they can contain arbitrary ruby code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ruby2.1-rubygem-bundler > 0-0 (version in image is 1.7.3-3.8).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Bounds check struct nfc_target arraysWhile running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18)This appears to be a legitimate lack of bounds checking innci_add_new_protocol(). Add the missing checks.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_sock_timeoutconn->sk maybe have been unlinked/freed while waiting for sco_conn_lockso this checks if the conn->sk is still valid by checking if it part ofsco_sk_list.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 131072 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=directdmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free of kernel socket in cleanup_bearer().syzkaller reported a use-after-free of UDP kernel socketin cleanup_bearer() without repro. [0][1]When bearer_disable() calls tipc_udp_disable(), cleanupof the UDP kernel socket is deferred by work callingcleanup_bearer().tipc_exit_net() waits for such works to finish by checkingtipc_net(net)->wq_count. However, the work decrements thecount too early before releasing the kernel socket,unblocking cleanup_net() and resulting in use-after-free.Let's move the decrement after releasing the socket incleanup_bearer().[0]:ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830[1]:BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfaHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: events cleanup_bearer
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Python 2.7.14 is vulnerable to a Heap-Buffer-Overflow as well as a Heap-Use-After-Free. Python versions prior to 2.7.14 may also be vulnerable and it appears that Python 2.7.17 and prior may also be vulnerable however this has not been confirmed. The vulnerability lies when multiply threads are handling large amounts of data. In both cases there is essentially a race condition that occurs. For the Heap-Buffer-Overflow, Thread 2 is creating the size for a buffer, but Thread1 is already writing to the buffer without knowing how much to write. So when a large amount of data is being processed, it is very easy to cause memory corruption using a Heap-Buffer-Overflow. As for the Use-After-Free, Thread3->Malloc->Thread1->Free's->Thread2-Re-uses-Free'd Memory. The PSRT has stated that this is not a security vulnerability due to the fact that the attacker must be able to run code, however in some situations, such as function as a service, this vulnerability can potentially be used by an attacker to violate a trust boundary, as such the DWF feels this issue deserves a CVE.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcmu: Fix possible page UAFtcmu_try_get_data_page() looks up pages under cmdr_lock, but it does nottake refcount properly and just returns page pointer. Whentcmu_try_get_data_page() returns, the returned page may have been freed bytcmu_blocks_release().We need to get_page() under cmdr_lock to avoid concurrenttcmu_blocks_release().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: Set BIO_THROTTLED when bio has been throttled1.In current process, all bio will set the BIO_THROTTLED flagafter __blk_throtl_bio().2.If bio needs to be throttled, it will start the timer andstop submit bio directly. Bio will submit inblk_throtl_dispatch_work_fn() when the timer expires.But inthe current process, if bio is throttled. The BIO_THROTTLEDwill be set to bio after timer start. If the bio has beencompleted, it may cause use-after-free blow.BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70Read of size 2 at addr ffff88801b8902d4 by task fio/26380 dump_stack+0x9b/0xce print_address_description.constprop.6+0x3e/0x60 kasan_report.cold.9+0x22/0x3a blk_throtl_bio+0x12f0/0x2c70 submit_bio_checks+0x701/0x1550 submit_bio_noacct+0x83/0xc80 submit_bio+0xa7/0x330 mpage_readahead+0x380/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Allocated by task 26380: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.2+0xc1/0xd0 kmem_cache_alloc+0x146/0x440 mempool_alloc+0x125/0x2f0 bio_alloc_bioset+0x353/0x590 mpage_alloc+0x3b/0x240 do_mpage_readpage+0xddf/0x1ef0 mpage_readahead+0x264/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Freed by task 0: kasan_save_stack+0x19/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x1b/0x30 __kasan_slab_free+0x111/0x160 kmem_cache_free+0x94/0x460 mempool_free+0xd6/0x320 bio_free+0xe0/0x130 bio_put+0xab/0xe0 bio_endio+0x3a6/0x5d0 blk_update_request+0x590/0x1370 scsi_end_request+0x7d/0x400 scsi_io_completion+0x1aa/0xe50 scsi_softirq_done+0x11b/0x240 blk_mq_complete_request+0xd4/0x120 scsi_mq_done+0xf0/0x200 virtscsi_vq_done+0xbc/0x150 vring_interrupt+0x179/0x390 __handle_irq_event_percpu+0xf7/0x490 handle_irq_event_percpu+0x7b/0x160 handle_irq_event+0xcc/0x170 handle_edge_irq+0x215/0xb20 common_interrupt+0x60/0x120 asm_common_interrupt+0x1e/0x40Fix this by move BIO_THROTTLED set into the queue_lock.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Cancel pending work at closing a MIDI substreamAt closing a USB MIDI output substream, there might be still a pendingwork, which would eventually access the rawmidi runtime object that isbeing released. For fixing the race, make sure to cancel the pendingwork at closing.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netem: fix return value if duplicate enqueue failsThere is a bug in netem_enqueue() introduced bycommit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")that can lead to a use-after-free.This commit made netem_enqueue() always return NET_XMIT_SUCCESSwhen a packet is duplicated, which can cause the parent qdisc's q.qlento be mistakenly incremented. When this happens qlen_notify() may beskipped on the parent during destruction, leaving a dangling pointerfor some classful qdiscs like DRR.There are two ways for the bug happen:- If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped.- If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped.In both cases NET_XMIT_SUCCESS is returned even though no packetsare enqueued at the netem qdisc.The fix is to defer the enqueue of the duplicate packet until afterthe original packet has been guaranteed to return NET_XMIT_SUCCESS.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block, bfq: fix possible UAF for bfqq->bic with merge chain1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | ^ | ^ | ^ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3process ref: 1 1 12) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | ^ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3process ref: 0 2 13) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> ^ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3process ref: 0 1 3In this case, IO from Process 1 will get bfqq2 from BIC1 first, and thenget bfqq3 through merge chain, and finially handle IO by bfqq3.Howerver, current code will think bfqq2 is owned by BIC1, like initialstate, and set bfqq2->bic to BIC1.bfq_insert_request-> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3Fix the problem by checking bfqq is from merge chain fist. And thismight fix a following problem reported by our syzkaller(unreproducible):==================================================================BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014Workqueue: kblockd blk_mq_requeue_workCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline]---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/xen-netback: prevent UAF in xenvif_flush_hash()During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,kfree_rcu does not exist inside the rcu read critical section, so ifkfree_rcu is called when the rcu grace period ends during the iteration,UAF occurs when accessing head->next after the entry becomes free.Therefore, to solve this, you need to change it to list_for_each_entry_safe.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """The commit 83fccfc3940c ("inet: fix potential deadlock inreqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() notto call del_timer_sync() from reqsk_timer_handler(), but it introduced asmall race window.Before the timer is called, expire_timers() calls detach_timer(timer, true)to clear timer->entry.pprev and marks it as not pending.If reqsk_queue_unlink() checks timer_pending() just after expire_timers()calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer willcontinue running and send multiple SYN+ACKs until it expires.The reported UAF could happen if req->sk is close()d earlier than the timerexpiration, which is 63s by default.The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->skLet's not use timer_pending() by passing the caller context to__inet_csk_reqsk_queue_drop().Note that reqsk timer is pinned, so the issue does not happen in mostuse cases. [1][0]BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0Use-after-free read at 0x00000000a891fb3a (in kfence-#1):bpf_sk_storage_get_tracing+0x2e/0x1b0bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1ddabpf_trace_run2+0x4c/0xc0tcp_rtx_synack+0xf9/0x100reqsk_timer_handler+0xda/0x3d0run_timer_softirq+0x292/0x8a0irq_exit_rcu+0xf5/0x320sysvec_apic_timer_interrupt+0x6d/0x80asm_sysvec_apic_timer_interrupt+0x16/0x20intel_idle_irq+0x5a/0xa0cpuidle_enter_state+0x94/0x273cpu_startup_entry+0x15e/0x260start_secondary+0x8a/0x90secondary_startup_64_no_verify+0xfa/0xfbkfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6allocated by task 0 on cpu 9 at 260507.901592s:sk_prot_alloc+0x35/0x140sk_clone_lock+0x1f/0x3f0inet_csk_clone_lock+0x15/0x160tcp_create_openreq_child+0x1f/0x410tcp_v6_syn_recv_sock+0x1da/0x700tcp_check_req+0x1fb/0x510tcp_v6_rcv+0x98b/0x1420ipv6_list_rcv+0x2258/0x26e0napi_complete_done+0x5b1/0x2990mlx5e_napi_poll+0x2ae/0x8d0net_rx_action+0x13e/0x590irq_exit_rcu+0xf5/0x320common_interrupt+0x80/0x90asm_common_interrupt+0x22/0x40cpuidle_enter_state+0xfb/0x273cpu_startup_entry+0x15e/0x260start_secondary+0x8a/0x90secondary_startup_64_no_verify+0xfa/0xfbfreed by task 0 on cpu 9 at 260507.927527s:rcu_core_si+0x4ff/0xf10irq_exit_rcu+0xf5/0x320sysvec_apic_timer_interrupt+0x6d/0x80asm_sysvec_apic_timer_interrupt+0x16/0x20cpuidle_enter_state+0xfb/0x273cpu_startup_entry+0x15e/0x260start_secondary+0x8a/0x90secondary_startup_64_no_verify+0xfa/0xfb
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4.0: Fix a use-after-free problem in the asynchronous open()Yang Erkun reports that when two threads are opening files at the sametime, and are forced to abort before a reply is seen, then the call tonfs_release_seqid() in nfs4_opendata_free() can result in ause-after-free of the pointer to the defunct rpc task of the otherthread.The fix is to ensure that if the RPC call is aborted before the call tonfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()in nfs4_open_release() before the rpc_task is freed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free of signing keyCustomers have reported use-after-free in @ses->auth_key.response withSMB2.1 + sign mounts which occurs due to following race:task A task Bcifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF*Fix this by ensuring that we have a valid @ses->auth_key.response bychecking whether @ses->ses_status is SES_GOOD or SES_EXITING with@ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAFin smb2_reconnect_server()"), we made sure to call ->logoff() onlywhen @ses was known to be good (e.g. valid ->auth_key.response), soit's safe to access signing key when @ses->ses_status == SES_EXITING.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix use after free on unloadSystem crash is observed with stack trace warning of use afterfree. There are 2 signals to tell dpc_thread to terminate (UNLOADINGflag and kthread_stop).On setting the UNLOADING flag when dpc_thread happens to run at the timeand sees the flag, this causes dpc_thread to exit and clean upitself. When kthread_stop is called for final cleanup, this causes useafter free.Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stopas the main signal to exit dpc_thread.[596663.812935] kernel BUG at mm/slub.c:294![596663.812950] invalid opcode: 0000 [#1] SMP PTI[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012[596663.812974] RIP: 0010:__slab_free+0x17d/0x360...[596663.813008] Call Trace:[596663.813022] ? __dentry_kill+0x121/0x170[596663.813030] ? _cond_resched+0x15/0x30[596663.813034] ? _cond_resched+0x15/0x30[596663.813039] ? wait_for_completion+0x35/0x190[596663.813048] ? try_to_wake_up+0x63/0x540[596663.813055] free_task+0x5a/0x60[596663.813061] kthread_stop+0xf3/0x100[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch_hfsc: make hfsc_qlen_notify() idempotenthfsc_qlen_notify() is not idempotent either and not friendlyto its callers, like fq_codel_dequeue(). Let's make it idempotentto ease qdisc_tree_reduce_backlog() callers' life:1. update_vf() decreases cl->cl_nactive, so we can check whether it isnon-zero before calling it.2. eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Kerberos). Supported versions that are affected are Java SE: 7u231, 8u221, 11.0.4 and 13; Java SE Embedded: 8u221. Difficult to exploit vulnerability allows unauthenticated attacker with network access via Kerberos to compromise Java SE, Java SE Embedded. While the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 6.8 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Security). Supported versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231. Difficult to exploit vulnerability allows unauthenticated attacker with network access via Kerberos to compromise Java SE, Java SE Embedded. While the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 6.8 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't query the device logical block size multiple timesDevices block sizes may change. One of these cases is a loop device byusing ioctl LOOP_SET_BLOCK_SIZE.While this may cause other issues like IO being rejected, in the case ofhfsplus, it will allocate a block by using that size and potentially writeout-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and thelatter function reads a different io_size.Using a new min_io_size initally set to sb_min_blocksize works for thepurposes of the original fix, since it will be set to the max betweenHFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use themax between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is notinitialized.Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024and 4096.The produced KASAN report before the fix looks like this:[ 419.944641] ==================================================================[ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a[ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678[ 419.947612][ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84[ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 419.950035] Call Trace:[ 419.950384] [ 419.950676] dump_stack_lvl+0x57/0x78[ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a[ 419.951830] print_report+0x14c/0x49e[ 419.952361] ? __virt_addr_valid+0x267/0x278[ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d[ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a[ 419.954231] kasan_report+0x89/0xb0[ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a[ 419.955367] hfsplus_read_wrapper+0x659/0xa0a[ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10[ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9[ 419.957214] ? _raw_spin_unlock+0x1a/0x2e[ 419.957772] hfsplus_fill_super+0x348/0x1590[ 419.958355] ? hlock_class+0x4c/0x109[ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10[ 419.959499] ? __pfx_string+0x10/0x10[ 419.960006] ? lock_acquire+0x3e2/0x454[ 419.960532] ? bdev_name.constprop.0+0xce/0x243[ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10[ 419.961799] ? pointer+0x3f0/0x62f[ 419.962277] ? __pfx_pointer+0x10/0x10[ 419.962761] ? vsnprintf+0x6c4/0xfba[ 419.963178] ? __pfx_vsnprintf+0x10/0x10[ 419.963621] ? setup_bdev_super+0x376/0x3b3[ 419.964029] ? snprintf+0x9d/0xd2[ 419.964344] ? __pfx_snprintf+0x10/0x10[ 419.964675] ? lock_acquired+0x45c/0x5e9[ 419.965016] ? set_blocksize+0x139/0x1c1[ 419.965381] ? sb_set_blocksize+0x6d/0xae[ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10[ 419.966179] mount_bdev+0x12f/0x1bf[ 419.966512] ? __pfx_mount_bdev+0x10/0x10[ 419.966886] ? vfs_parse_fs_string+0xce/0x111[ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10[ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10[ 419.968073] legacy_get_tree+0x104/0x178[ 419.968414] vfs_get_tree+0x86/0x296[ 419.968751] path_mount+0xba3/0xd0b[ 419.969157] ? __pfx_path_mount+0x10/0x10[ 419.969594] ? kmem_cache_free+0x1e2/0x260[ 419.970311] do_mount+0x99/0xe0[ 419.970630] ? __pfx_do_mount+0x10/0x10[ 419.971008] __do_sys_mount+0x199/0x1c9[ 419.971397] do_syscall_64+0xd0/0x135[ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 419.972233] RIP: 0033:0x7c3cb812972e[ 419.972564] Code: 48 8b 0d f5 46 0d 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 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48[ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5[ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e[ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In Sudo through 1.8.29, an attacker with access to a Runas ALL sudoer account can impersonate a nonexistent user by invoking sudo with a numeric uid that is not associated with any user. NOTE: The software maintainer believes that this is not a vulnerability because running a command via sudo as a user not present in the local password database is an intentional feature. Because this behavior surprised some users, sudo 1.8.30 introduced an option to enable/disable this behavior with the default being disabled. However, this does not change the fact that sudo was behaving as intended, and as documented, in earlier versions
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- sudo > 0-0 (version in image is 1.8.27-4.54.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Free buffers when a used dynamic event is removedAfter 65536 dynamic events have been added and removed, the "type" fieldof the event then uses the first type number that is available (notcurrently used by other events). A type number is the identifier of thebinary blobs in the tracing ring buffer (known as events) to map them tologic that can parse the binary blob.The issue is that if a dynamic event (like a kprobe event) is traced andis in the ring buffer, and then that event is removed (because it isdynamic, which means it can be created and destroyed), if another dynamicevent is created that has the same number that new event's logic onparsing the binary blob will be used.To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # doneFor every iteration of the above, the writing to the kprobe_events willremove the old event and create a new one (with the same format) andincrease the type number to the next available on until the type numberreaches over 65535 which is the max number for the 16 bit type. After itreaches that number, the logic to allocate a new number simply looks forthe next available number. When an dynamic event is removed, that numberis then available to be reused by the next dynamic event created. That is,once the above reaches the max number, the number assigned to the event inthat loop will remain the same.Now that means deleting one dynamic event and created another will reusethe previous events type number. This is where bad things can happen.After the above loop finishes, the kprobes/foo event which reads thedo_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enableNow if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_eventsAnd now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="���������������������������������������---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: use timestamp to check for set element timeoutAdd a timestamp field at the beginning of the transaction, store itin the nftables per-netns area.Update set backend .insert, .deactivate and sync gc path to use thetimestamp, this avoids that an element expires while control planetransaction is still unfinished..lookup and .update, which are used from packet path, still use thecurrent time to check if the element has expired. And .get path and dumpalso since this runs lockless under rcu read size lock. Then, there isasync gc which also needs to check the current time since it runsasynchronously from a workqueue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix out-of-bounds access in ops_initnet_alloc_generic is called by net_alloc, which is called without anylocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. Itis read twice, first to allocate an array, then to set s.len, which islater used to limit the bounds of the array access.It is possible that the array is allocated and another thread isregistering a new pernet ops, increments max_gen_ptrs, which is then usedto set s.len with a larger than allocated length for the variable array.Fix it by reading max_gen_ptrs only once in net_alloc_generic. Ifmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Ensure the copied buf is NUL terminatedCurrently, we allocate a count-sized kernel buffer and copy count fromuserspace to that buffer. Later, we use kstrtouint on this buffer but wedon't ensure that the string is terminated inside the buffer, this canlead to OOB read when using kstrtouint. Fix this issue by usingmemdup_user_nul instead of memdup_user.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: Fix use-after-free when removing resource in vmci_resource_remove()When removing a resource from vmci_resource_table invmci_resource_remove(), the search is performed using the resourcehandle by comparing context and resource fields.It is possible though to create two resources with different typesbut same handle (same context and resource fields).When trying to remove one of the resources, vmci_resource_remove()may not remove the intended one, but the object will still be freedas in the case of the datagram type in vmci_datagram_destroy_handle().vmci_resource_table will still hold a pointer to this freed resourceleading to a use-after-free vulnerability.BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0This change ensures the type is also checked when removingthe resource from vmci_resource_table in vmci_resource_remove().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: Disallow replacing of child qdisc from one parent to anotherLion Ackermann was able to create a UAF which can be abused for privilegeescalation with the following scriptStep 1. create root qdisctc qdisc add dev lo root handle 1:0 drrstep2. a class for packet aggregation do demonstrate uaftc class add dev lo classid 1:1 drrstep3. a class for nestingtc class add dev lo classid 1:2 drrstep4. a class to graft qdisc totc class add dev lo classid 1:3 drrstep5.tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024step6.tc qdisc add dev lo parent 1:2 handle 3:0 drrstep7.tc class add dev lo classid 3:1 drrstep 8.tc qdisc add dev lo parent 3:1 handle 4:0 pfifostep 9. Display the class/qdisc layouttc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kbtc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2step10. trigger the bug <=== prevented by this patchtc qdisc replace dev lo parent 1:3 handle 4:0step 11. Redisplay again the qdiscs/classestc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kbtc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2Observe that a) parent for 4:0 does not change despite the replace request.There can only be one parent. b) refcount has gone up by two for 4:0 andc) both class 1:3 and 3:1 are pointing to it.Step 12. send one packet to plugecho "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))step13. send one packet to the grafted fifoecho "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))step14. lets trigger the uaftc class delete dev lo classid 1:3tc class delete dev lo classid 1:1The semantics of "replace" is for a del/add _on the same node_ and nota delete from one node(3:1) and add to another node (1:3) as in step10.While we could "fix" with a more complex approach there could beconsequences to expectations so the patch takes the preventive approach of"disallow such config".Joint work with Lion Ackermann
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: amd8111: Fix PCI device reference count leakfor_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULLinput parameter, there is no problem for the 'Device not found' branch.For the normal path, add pci_dev_put() in amd_gpio_exit().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in l2tp_ip6_sendmsgWhen len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will beoverflow. To fix, we can follow what udpv6 does and subtract thetranshdrlen from the max.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in __ip6_append_dataResurrect ubsan overflow checks and ubsan report this warning,fix it by change the variable [length] type to size_t.UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:192147479552 + 8567 cannot be represented in type 'int'CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170Changes since v1:-Change the variable [length] type to unsigned, as Eric Dumazet suggested.Changes since v2:-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.Changes since v3:-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, asJakub Kicinski suggested.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return valuecpufreq_cpu_get may return NULL. To avoid NULL-dereference check itand return 0 in case of error.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Handle TD clearing for multiple streams caseWhen multiple streams are in use, multiple TDs might be in flight whenan endpoint is stopped. We need to issue a Set TR Dequeue Pointer foreach, to ensure everything is reset properly and the caches cleared.Change the logic so that any N>1 TDs found active for different streamsare deferred until after the first one is processed, callingxhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() toqueue another command until we are done with all of them. Also changethe error/"should never happen" paths to ensure we at least clear anyaffected TDs, even if we can't issue a command to clear the hardwarecache, and complain loudly with an xhci_warn() if this ever happens.This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correctassumptions about number of rings per endpoint.") early on in the XHCIdriver's life, when stream support was first added.It was then identified but not fixed nor made into a warning in commit674f8438c121 ("xhci: split handling halted endpoints into two steps"),which added a FIXME comment for the problem case (without materiallychanging the behavior as far as I can tell, though the new logic madethe problem more obvious).Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back somecached cancelled URBs."), it was acknowledged again.[Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cachedcancelled URBs.") was a targeted regression fix to the previously mentionedpatch. Users reported issues with usb stuck after unmounting/disconnectingUAS devices. This rolled back the TD clearing of multiple streams to itsoriginal state.]Apparently the commit author was aware of the problem (yet still choseto submit it): It was still mentioned as a FIXME, an xhci_dbg() wasadded to log the problem condition, and the remaining issue was mentionedin the commit description. The choice of making the log type xhci_dbg()for what is, at this point, a completely unhandled and known brokencondition is puzzling and unfortunate, as it guarantees that no actualusers would see the log in production, thereby making it nighundebuggable (indeed, even if you turn on DEBUG, the message doesn'treally hint at there being a problem at all).It took me *months* of random xHC crashes to finally find a reliablerepro and be able to do a deep dive debug session, which could all havebeen avoided had this unhandled, broken condition been actually reportedwith a warning, as it should have been as a bug intentionally left inunfixed (never mind that it shouldn't have been left in at all).> Another fix to solve clearing the caches of all stream rings with> cancelled TDs is needed, but not as urgent.3 years after that statement and 14 years after the original bug wasintroduced, I think it's finally time to fix it. And maybe next timelet's not leave bugs unfixed (that are actually worse than the originalbug), and let's actually get people to review kernel commits please.Fixes xHC crashes and IOMMU faults with UAS devices when handlingerrors/faults. Easiest repro is to use `hdparm` to mark an early sector(e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.At least in the case of JMicron controllers, the read errors end uphaving to cancel two TDs (for two queued requests to different streams)and the one that didn't get cleared properly ends up faulting the xHCentirely when it tries to access DMA pages that have since been unmapped,referred to by the stale TDs. This normally happens quickly (after twoor three loops). After this fix, I left the `cat` in a loop runningovernight and experienced no xHC failures, with all read errorsrecovered properly. Repro'd and tested on an Apple M1 Mac Mini(dwc3 host).On systems without an IOMMU, this bug would instead silently corruptfreed memory, making this a---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write errorEnsure index in rtl2830_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write errorEnsure index in rtl2832_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.[hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue in`cm_helper_translate_curve_to_degamma_hw_format` function. The issuecould occur when the index 'i' exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix ppp_async_encode() illegal accesssyzbot reported an issue in ppp_async_encode() [1]In this case, pppoe_sendmsg() is called with a zero size.Then ppp_async_encode() is called with an empty skb.BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: fix uninit-value use in udf_get_fileshortadCheck for overflow when computing alen in udf_current_aext to mitigatelater uninit-value use in udf_get_fileshortad KMSAN bug[1].After applying the patch reproducer did not trigger any issue[2].[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bnep: fix wild-memory-access in proto_unregisterThere's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAs bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()will cleanup all resource. Then when remove bnep module will callbnep_sock_cleanup() to cleanup sock's resource.To solve above issue just return bnep_sock_init()'s return value inbnep_exit().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmode should keep reference to parentThe altmode device release refers to its parent device, but without keepinga reference to it.When registering the altmode, get a reference to the parent and put it inthe release function.Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issueslike this:[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)[ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)[ 46.612867] ==================================================================[ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129[ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48[ 46.614538][ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535[ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 46.616042] Workqueue: events kobject_delayed_cleanup[ 46.616446] Call Trace:[ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c[ 46.617112] ? typec_altmode_release+0x38/0x129[ 46.617470] print_report+0x14c/0x49e[ 46.617769] ? rcu_read_unlock_sched+0x56/0x69[ 46.618117] ? __virt_addr_valid+0x19a/0x1ab[ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d[ 46.618807] ? typec_altmode_release+0x38/0x129[ 46.619161] kasan_report+0x8d/0xb4[ 46.619447] ? typec_altmode_release+0x38/0x129[ 46.619809] ? process_scheduled_works+0x3cb/0x85f[ 46.620185] typec_altmode_release+0x38/0x129[ 46.620537] ? process_scheduled_works+0x3cb/0x85f[ 46.620907] device_release+0xaf/0xf2[ 46.621206] kobject_delayed_cleanup+0x13b/0x17a[ 46.621584] process_scheduled_works+0x4f6/0x85f[ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10[ 46.622353] ? hlock_class+0x31/0x9a[ 46.622647] ? lock_acquired+0x361/0x3c3[ 46.622956] ? move_linked_works+0x46/0x7d[ 46.623277] worker_thread+0x1ce/0x291[ 46.623582] ? __kthread_parkme+0xc8/0xdf[ 46.623900] ? __pfx_worker_thread+0x10/0x10[ 46.624236] kthread+0x17e/0x190[ 46.624501] ? kthread+0xfb/0x190[ 46.624756] ? __pfx_kthread+0x10/0x10[ 46.625015] ret_from_fork+0x20/0x40[ 46.625268] ? __pfx_kthread+0x10/0x10[ 46.625532] ret_from_fork_asm+0x1a/0x30[ 46.625805] [ 46.625953][ 46.626056] Allocated by task 678:[ 46.626287] kasan_save_stack+0x24/0x44[ 46.626555] kasan_save_track+0x14/0x2d[ 46.626811] __kasan_kmalloc+0x3f/0x4d[ 46.627049] __kmalloc_noprof+0x1bf/0x1f0[ 46.627362] typec_register_port+0x23/0x491[ 46.627698] cros_typec_probe+0x634/0xbb6[ 46.628026] platform_probe+0x47/0x8c[ 46.628311] really_probe+0x20a/0x47d[ 46.628605] device_driver_attach+0x39/0x72[ 46.628940] bind_store+0x87/0xd7[ 46.629213] kernfs_fop_write_iter+0x1aa/0x218[ 46.629574] vfs_write+0x1d6/0x29b[ 46.629856] ksys_write+0xcd/0x13b[ 46.630128] do_syscall_64+0xd4/0x139[ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 46.630820][ 46.630946] Freed by task 48:[ 46.631182] kasan_save_stack+0x24/0x44[ 46.631493] kasan_save_track+0x14/0x2d[ 46.631799] kasan_save_free_info+0x3f/0x4d[ 46.632144] __kasan_slab_free+0x37/0x45[ 46.632474]---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds write in trie_get_next_key()trie_get_next_key() allocates a node stack with size trie->max_prefixlen,while it writes (trie->max_prefixlen + 1) nodes to the stack when it hasfull paths from the root to leaves. For example, consider a trie withmax_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with.prefixlen = 8 make 9 nodes be written on the node stack with size 8.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004[...][ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[...][ 57.331328] Call Trace:[ 57.331477] [...][ 57.333511] ? do_user_addr_fault+0x3e5/0x740[ 57.333778] ? exc_page_fault+0x70/0x170[ 57.334016] ? asm_exc_page_fault+0x2b/0x30[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0[ 57.335164] ocfs2_xa_set+0x704/0xcf0[ 57.335381] ? _raw_spin_unlock+0x1a/0x40[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20[ 57.335915] ? trace_preempt_on+0x1e/0x70[ 57.336153] ? start_this_handle+0x16c/0x500[ 57.336410] ? preempt_count_sub+0x50/0x80[ 57.336656] ? _raw_read_unlock+0x20/0x40[ 57.336906] ? start_this_handle+0x16c/0x500[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0[ 57.337706] ? ocfs2_start_trans+0x13d/0x290[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0[ 57.338207] ? dput+0x46/0x1c0[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30[ 57.338948] __vfs_removexattr+0x92/0xc0[ 57.339182] __vfs_removexattr_locked+0xd5/0x190[ 57.339456] ? preempt_count_sub+0x50/0x80[ 57.339705] vfs_removexattr+0x5f/0x100[...]Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->ocfs2_xa_value_truncate() with -ENOMEM.In this case the comment mentions that we can return 0 ifocfs2_xa_cleanup_value_truncate() is going to wipe the entryanyway. But the following 'rc' check is wrong and execution flow do'ocfs2_xa_remove_entry(loc);' twice:* 1st: in ocfs2_xa_cleanup_value_truncate();* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.Fix this by skipping the 2nd removal of the same entry and makingsyzkaller repro happy.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out of bounds reads when finding clock sourcesThe current USB-audio driver code doesn't check bLength of eachdescriptor at traversing for clock descriptors. That is, when adevice provides a bogus descriptor with a shorter bLength, the drivermight hit out-of-bounds reads.For addressing it, this patch adds sanity checks to the validatorfunctions for the clock descriptor traversal. When the descriptorlength is shorter than expected, it's skipped in the loop.For the clock source and clock multiplier descriptors, we can justcheck bLength against the sizeof() of each descriptor type.OTOH, the clock selector descriptor of UAC2 and UAC3 has an arrayof bNrInPins elements and two more fields at its tail, hence thosehave to be checked in addition to the sizeof() check.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctlFix an issue detected by syzbot with KASAN:BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/core.c:416 [inline]BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0drivers/acpi/nfit/core.c:459The issue occurs in cmd_to_func when the call_pkg->nd_reserved2array is accessed without verifying that call_pkg points to a bufferthat is appropriately sized as a struct nd_cmd_pkg. This can leadto out-of-bounds access and undefined behavior if the buffer does nothave sufficient space.To address this, a check was added in acpi_nfit_ctl() to ensure thatbuf is not NULL and that buf_len is less than sizeof(*call_pkg)before accessing it. This ensures safe access to the members ofcall_pkg, including the nd_reserved2 array.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Prevent integer overflow issueIn the expression "cmd.wqe_size * cmd.wr_count", both variables are u32values that come from the user so the multiplication can lead to integerwrapping. Then we pass the result to uverbs_request_next_ptr() which alsocould potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"multiplication can also overflow on 32bit systems although it's fine on64bit systems.This patch does two things. First, I've re-arranged the condition inuverbs_request_next_ptr() so that the use controlled variable "len" is onone side of the comparison by itself without any math. Then I've modifiedall the callers to use size_mul() for the multiplications.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: SVG's <use> element could have been used to load unexpected content that could have executed script in certain circumstances. While the specification seems to allow this, other browsers do not, and web developers relied on this property for script security so gecko's implementation was aligned with theirs. This vulnerability affects Firefox < 99.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: An attacker could have written a value to the first element in a zero-length JavaScript array. Although the array was zero-length, the value was not written to an invalid memory address. This vulnerability affects Firefox < 104.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: The Zone-Based Firewall (ZBFW) functionality in Cisco IOS, possibly 15.4 and earlier, and IOS XE, possibly 3.13 and earlier, mishandles zone checking for existing sessions, which allows remote attackers to bypass intended resource-access restrictions via spoofed traffic that matches one of these sessions, aka Bug IDs CSCun94946 and CSCun96847.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: A ReDoS issue was discovered in the Time component through 0.2.1 in Ruby through 3.2.1. The Time parser mishandles invalid URLs that have specific characters. It causes an increase in execution time for parsing strings to Time objects. The fixed versions are 0.1.1 and 0.2.2.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ruby2.1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fix kernel crash if commands allocation failsIf the commands allocation fails in nvmet_tcp_alloc_cmds()the kernel crashes in nvmet_tcp_release_queue_work() because ofa NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008Fix the bug by setting queue->nr_cmds to zero in casenvmet_tcp_alloc_cmd() fails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dpaa: Pad packets to ETH_ZLENWhen sending packets under 60 bytes, up to three bytes of the bufferfollowing the data may be leaked. Avoid this by extending all packets toETH_ZLEN, ensuring nothing is leaked in the padding. This bug can bereproduced by running $ ping -s 11 destination
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sendinggarbage on the four reserved tcp bits (th->res1)Use skb_put_zero() to clear the whole TCP header,as done in nf_reject_ip_tcphdr_put()BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctlHulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock heldby ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can beconcurrent.ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.ubi_detach is bug-free because it uses reference counting to preventconcurrency. However, uif_init and uif_close in ubi_attach may race withubi_cdev_ioctl.uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_delAnd uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double freeThe cause of this problem is that commit 714fb87e8bc0 make device"available" before it becomes accessible via sysfs. Therefore, weroll back the modification. We will fix the race condition betweenubi device creation and udev by removing ubi_get_device invol_attribute_show and dev_attribute_show.This avoids accessinguninitialized ubi_devices[ubi_num].ubi_get_device is used to prevent devices from being deleted duringsysfs execution. However, now kernfs ensures that devices will notbe deleted before all reference counting are released.The key process is shown in the following stack.device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix possible use-after-free in transport error_recovery workWhile nvme_tcp_submit_async_event_work is checking the ctrl and queuestate before preparing the AER command and scheduling io_work, in orderto fully prevent a race where this check is not reliable the errorrecovery work must flush async_event_work before continuing to destroythe admin queue after setting the ctrl state to RESETTING such thatthere is no race .submit_async_event and the error recovery handleritself changing the ctrl state.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix a possible use-after-free in controller reset during loadUnlike .queue_rq, in .submit_async_event drivers may not check the ctrlreadiness for AER submission. This may lead to a use-after-freecondition that was observed with nvme-tcp.The race condition may happen in the following scenario:1. driver executes its reset_ctrl_work2. -> nvme_stop_ctrl - flushes ctrl async_event_work3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling4. teardown admin queue (which releases the queue socket)5. AEN processed, submits another AER, calling the driver to submit6. driver attempts to send the cmd==> use-after-freeIn order to fix that, add ctrl state check to validate the ctrlis actually able to accept the AER submission.This addresses the above race in controller resets because the driverduring teardown should:1. change ctrl state to RESETTING2. flush async_event_work (as well as other async work elements)So after 1,2, any other AER command will find thectrl state to be RESETTING and bail out without submitting the AER.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: add flush_workqueue to prevent uafOur detector found a concurrent use-after-free bug when detaching anNCI device. The main reason for this bug is the unexpected schedulingbetween the used delayed mechanism (timer and workqueue).The race can be demonstrated below:Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work)nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] |... | Workernci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2]In short, the cleanup routine thought that the cmd_timer has alreadybeen detached by [1] but the mod_timer can re-attach the timer [2], evenit is already released [3], resulting in UAF.This UAF is easy to trigger, crash trace by POC is like below[ 66.703713] ==================================================================[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33[ 66.703974][ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work[ 66.703974] Call Trace:[ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d[ 66.703974] print_report.cold+0x5e/0x5db[ 66.703974] ? enqueue_timer+0x448/0x490[ 66.703974] kasan_report+0xbe/0x1c0[ 66.703974] ? enqueue_timer+0x448/0x490[ 66.703974] enqueue_timer+0x448/0x490[ 66.703974] __mod_timer+0x5e6/0xb80[ 66.703974] ? mark_held_locks+0x9e/0xe0[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410[ 66.703974] ? queue_work_on+0x61/0x80[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130[ 66.703974] process_one_work+0x8bb/0x1510[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230[ 66.703974] ? rwlock_bug.part.0+0x90/0x90[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50[ 66.703974] worker_thread+0x575/0x1190[ 66.703974] ? process_one_work+0x1510/0x1510[ 66.703974] kthread+0x2a0/0x340[ 66.703974] ? kthread_complete_and_exit+0x20/0x20[ 66.703974] ret_from_fork+0x22/0x30[ 66.703974] [ 66.703974][ 66.703974] Allocated by task 267:[ 66.703974] kasan_save_stack+0x1e/0x40[ 66.703974] __kasan_kmalloc+0x81/0xa0[ 66.703974] nci_allocate_device+0xd3/0x390[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0[ 66.703974] tty_ioctl+0x764/0x1310[ 66.703974] __x64_sys_ioctl+0x122/0x190[ 66.703974] do_syscall_64+0x3b/0x90[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 66.703974][ 66.703974] Freed by task 406:[ 66.703974] kasan_save_stack+0x1e/0x40[ 66.703974] kasan_set_track+0x21/0x30[ 66.703974] kasan_set_free_info+0x20/0x30[ 66.703974] __kasan_slab_free+0x108/0x170[ 66.703974] kfree+0xb0/0x330[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0[ 66.703974] nci_uart_tty_close+0xdf/0x180[ 66.703974] tty_ldisc_kill+0x73/0x110[ 66.703974] tty_ldisc_hangup+0x281/0x5b0[ 66.703974] __tty_hangup.part.0+0x431/0x890[ 66.703974] tty_release+0x3a8/0xc80[ 66.703974] __fput+0x1f0/0x8c0[ 66.703974] task_work_run+0xc9/0x170[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0[ 66.703974] syscall_exit_to_user_mode+0x19/0x50[ 66.703974] do_syscall_64+0x48/0x90[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/net/ethernet/qualcomm/emac/emac.c if a physically proximate attacker unplugs an emac based device.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix uaf in pvr2_context_set_notify[Syzbot reported]BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Workqueue: usb_hub_wq hub_eventCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272Freed by task 906:kasan_save_stack+0x33/0x50 mm/kasan/common.c:47kasan_save_track+0x14/0x30 mm/kasan/common.c:68kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640poison_slab_object mm/kasan/common.c:241 [inline]__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257kasan_slab_free include/linux/kasan.h:184 [inline]slab_free_hook mm/slub.c:2121 [inline]slab_free mm/slub.c:4299 [inline]kfree+0x105/0x340 mm/slub.c:4409pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158[Analyze]Task A set disconnect_flag = !0, which resulted in Task B's condition being metand releasing mp, leading to this issue.[Fix]Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()to avoid this issue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: avoid double free special payloadIf a discard request needs to be retried, and that retry may fail beforea new special payload is added, a double free will result. Clear theRQF_SPECIAL_LOAD when the request is cleaned.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aacraid: Fix double-free on probe failureaac_probe_one() calls hardware-specific init functions through theaac_driver_ident::init pointer, all of which eventually call down toaac_init_adapter().If aac_init_adapter() fails after allocating memory for aac_dev::queues,it frees the memory but does not clear that member.After the hardware-specific init function returns an error,aac_probe_one() goes down an error path that frees the memory pointed toby aac_dev::queues, resulting.in a double-free.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: call the security_mmap_file() LSM hook in remap_file_pages()The remap_file_pages syscall handler calls do_mmap() directly, whichdoesn't contain the LSM security check. And if the process has calledpersonality(READ_IMPLIES_EXEC) before and remap_file_pages() is called forRW pages, this will actually result in remapping the pages to RWX,bypassing a W^X policy enforced by SELinux.So we should check prot by security_mmap_file LSM hook in theremap_file_pages syscall handler before do_mmap() is called. Otherwise, itpotentially permits an attacker to bypass a W^X policy enforced bySELinux.The bypass is similar to CVE-2016-10044, which bypass the same thing viaAIO and can be found in [1].The PoC:$ cat > test.cint main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd);}$ gcc test.c -o test$ ./test | grep rwx7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)[PM: subject line tweaks]
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: asihpi: Fix potential OOB array accessASIHPI driver stores some values in the static array upon a responsefrom the driver, and its index depends on the firmware. We shouldn'ttrust it blindly.This patch adds a sanity check of the array index to fit in the arraysize.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instanceDeleting an NPIV instance requires all fabric ndlps to be released beforean NPIV's resources can be torn down. Failure to release fabric ndlpsbeforehand opens kref imbalance race conditions. Fix by forcing the DA_IDto complete synchronously with usage of wait_queue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/rdmavt: add lock to call to rvt_error_qp to prevent a race conditionThe documentation of the function rvt_error_qp says both r_lock and s_lockneed to be held when calling that function. It also asserts using lockdepthat both of those locks are held. However, the commit I referenced inFixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback nolonger covered by r_lock. This results in the lockdep assertion failingand also possibly in a race condition.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix race condition between reset and nvme_dev_disable()nvme_dev_disable() modifies the dev->online_queues field, thereforenvme_pci_update_nr_queues() should avoid racing against it, otherwisewe could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]Fix the bug by locking the shutdown_lock mutex before usingdev->online_queues. Give up if nvme_dev_disable() is running or ifit has been executed already.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix race condition by adding filter's intermediate sync stateFix a race condition in the i40e driver that leads to MAC/VLAN filtersbecoming corrupted and leaking. Address the issue that occurs underheavy load when multiple threads are concurrently modifying MAC/VLANfilters by setting mac and port VLAN.1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan().2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac().3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption.Reproduction steps:1. Spawn multiple VFs.2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host.3. Observe errors in dmesg:"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX".Exact code for stable reproduction Intel can't open-source now.The fix involves implementing a new intermediate filter state,I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.These filters cannot be deleted from the hash list directly butmust be removed using the full process.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: After a VR Process is destroyed, a reference to it may have been retained and used, leading to a use-after-free and potentially exploitable crash. This vulnerability affects Thunderbird < 91.8 and Firefox ESR < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: When importing a revoked key that specified key compromise as the revocation reason, Thunderbird did not update the existing copy of the key that was not yet revoked, and the existing key was kept as non-revoked. Revocation statements that used another revocation reason, or that didn't specify a revocation reason, were unaffected. This vulnerability affects Thunderbird < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: By using a link with rel="localization" a use-after-free could have been triggered by destroying an object during JavaScript execution and then referencing the object through a freed pointer, leading to a potential exploitable crash. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: When generating the assembly code for MLoadTypedArrayElementHole, an incorrect AliasSet was used. In conjunction with another vulnerability this could have been used for an out of bounds memory read. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvneta: Prevent out of bounds read in mvneta_config_rss()The pp->indir[0] value comes from the user. It is passed to: if (cpu_online(pp->rxq_def))inside the mvneta_percpu_elect() function. It needs bounds checkedingto ensure that it is not beyond the end of the cpu bitmap.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: fix panic on out-of-bounds guest IRQAs guest_irq is coming from KVM_IRQFD API call, it may triggercrash in svm_update_pi_irte() due to out-of-bounds:crash> btPID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002bVmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() onout-of-bounds guest IRQ), so we can just copy source from that to fixthis.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Fix UAF in bcm_proc_show()BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80Read of size 8 at addr ffff888155846230 by task cat/7862CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdAllocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdFreed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0bcm_op is freed before procfs entry be removed in bcm_release(),this lead to bcm_proc_show() may read the freed bcm_op.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- wget > 0-0 (version in image is 1.14-21.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix UAF in error pathSam Page (sam4k) working with Trend Micro Zero Day Initiative reporteda UAF in the tipc_buf_append() error path:BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0linux/net/core/skbuff.c:1183Read of size 8 at addr ffff88804d2a7c80 by task poc/8034CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.0-debian-1.16.0-5 04/01/2014Call Trace: __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_---truncated---
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Fix uninitialized value issue in from_kuid and from_kgidocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid ina trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.Initialize all fields of newattrs to avoid uninitialized variables, bychecking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when attempting to join an aborted transactionWhen we are trying to join the current transaction and if it's aborted,we read its 'aborted' field after unlocking fs_info->trans_lock andwithout holding any extra reference count on it. This means that aconcurrent task that is aborting the transaction may free the transactionbefore we read its 'aborted' field, leading to a use-after-free.Fix this by reading the 'aborted' field while holding fs_info->trans_locksince any freeing task must first acquire that lock and setfs_info->running_transaction to NULL before freeing the transaction.This was reported by syzbot and Dmitry with the following stack tracesfrom KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211: fix potential double free on mesh joinWhile commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leavingmesh") fixed a memory leak on mesh leave / teardown it introduced apotential memory corruption caused by a double free when rejoining themesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie);This double free / kernel panics can be reproduced by using wpa_supplicantwith an encrypted mesh (if set up without encryption via "iw" thenifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-meshNote that typically these commands are not used / working when usingwpa_supplicant. And it seems that wpa_supplicant or wpa_cli are goingthrough a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh joinwhere the NETDEV_UP resets the mesh.ie to NULL via a memcpy ofdefault_mesh_setup in cfg80211_netdev_notifier_call, which then avoidsthe memory corruption, too.The issue was first observed in an application which was not usingwpa_supplicant but "Senf" instead, which implements its own calls tonl80211.Fixing the issue by removing the kfree()'ing of the mesh IE in the meshjoin function and leaving it solely up to the mesh leave to free themesh IE.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Don't free decrypted memoryIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus device UIO driver could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the gpadlto decide whether to free the memory.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
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:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC session. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-0169.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u231, 8u221, 11.0.4 and 13; Java SE Embedded: 8u221. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 5.9 (Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: JavaFX). The supported version that is affected is Java SE: 8u231. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 5.9 (Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV socketsTCP_SYN_RECV state is really special, it is only used bycross-syn connections, mostly used by fuzzers.In the following crash [1], syzbot managed to trigger a divideby zero in tcp_rcv_space_adjust()A socket makes the following state transitions,without ever calling tcp_init_transfer(),meaning tcp_init_buffer_space() is also not called. TCP_CLOSEconnect() TCP_SYN_SENT TCP_SYN_RECVshutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1To fix this issue, change tcp_shutdown() to notperform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,which makes no sense anyway.When tcp_rcv_state_process() later changes socket statefrom TCP_SYN_RECV to TCP_ESTABLISH, then look atsk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,and send a FIN packet from a sane socket state.This means tcp_send_fin() can now be called from BHcontext, and must use GFP_ATOMIC allocations.[1]divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2daFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0Call Trace: tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 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+0x199/0x250 net/socket.c:3034 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:0x7faeb6363db9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012bRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001cR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python-requests > 0-0 (version in image is 2.24.0-8.23.1).
-
Description: REXML is an XML toolkit for Ruby. The REXML gem before 3.3.9 has a ReDoS vulnerability when it parses an XML that has many digits between &# and x...; in a hex numeric character reference (&#x...;). This does not happen with Ruby 3.2 or later. Ruby 3.1 is the only affected maintained Ruby. The REXML gem 3.3.9 or later include the patch to fix the vulnerability.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ruby2.1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- expat > 0-0 (version in image is 2.7.1-21.43.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi->poll_ownernon atomically. The ->poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Prevent USB core invalid event buffer address accessThis commit addresses an issue where the USB core could access aninvalid event buffer address during runtime suspend, potentially causingSMMU faults and other memory issues in Exynos platforms. The problemarises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.To prevent this hardware quirk on Exynos platforms, this commit ensuresthat the event buffer address is not cleared by software when the USBcore is active during runtime suspend by checking its status beforeclearing the buffer address.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix use-after-free in tw_timer_handlerA real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20This issue was also reported since 2017 in the thread [1],unfortunately, the issue was still can be reproduced after fixingDCCP.The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a netnamespace is destroyed since tcp_sk_ops is registered befroreipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_opsin the list of pernet_list. There will be a use-after-free onnet->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_netif there are some inflight time-wait timers.This bug is not introduced by commit f2bf415cfed7 ("mib: add net toNET_ADD_STATS_BH") since the net_statistics is a global variableinstead of dynamic allocation and freeing. Actually, commit61a7e26028b9 ("mib: put net statistics on struct net") introducesthe bug since it put net statistics on struct net and free it whennet namespace is destroyed.Moving init_ipv4_mibs() to the front of tcp_init() to fix this bugand replace pr_crit() with panic() since continuing is meaninglesswhen init_ipv4_mibs() fails.[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock when cloning inline extents and using qgroupsThere are a few exceptional cases where cloning an inline extent needs tocopy the inline extent data into a page of the destination inode.When this happens, we end up starting a transaction while having a dirtypage for the destination inode and while having the range locked in thedestination's inode iotree too. Because when reserving metadata spacefor a transaction we may need to flush existing delalloc in case there isnot enough free space, we have a mechanism in place to prevent a deadlock,which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock whencloning inline extent and low on free metadata space").However when using qgroups, a transaction also reserves metadata qgroupspace, which can also result in flushing delalloc in case there is notenough available space at the moment. When this happens we deadlock, sinceflushing delalloc requires locking the file range in the inode's iotreeand the range was already locked at the very beginning of the cloneoperation, before attempting to start the transaction.When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extent_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747.556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] process_one_work+0x1aa/0x340 [72747.556426] worker_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964] __schedule+0x296/0x760 [72747.566968] ? finish_wait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extent_writepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] process_one_work+0x1aa/0x340 [72747.567202] worker_thread+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] task:fsstress state:D stack: ---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: wait and exit until all work queues are doneOn some host, a crash could be triggered simply by repeating thesecommands several times: # modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc [] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthread_flush_work_fn+0x10/0x10 [] ? ret_from_fork+0x35/0x40When removing the TIPC module, the UDP tunnel sock will be delayed torelease in a work queue as sock_release() can't be done in rtnl_lock().If the work queue is schedule to run after the TIPC module is removed,kernel will crash as the work queue function cleanup_beareri() code nolonger exists when trying to invoke it.To fix it, this patch introduce a member wq_count in tipc_net to trackthe numbers of work queues in schedule, and wait and exit until allwork queues are done in tipc_exit_net().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix vlan tunnel dst refcnt when egressingThe egress tunnel code uses dst_clone() and directly sets the resultwhich is wrong because the entry might have 0 refcnt or be already deleted,causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]when a refcnt couldn't be taken. Fix it by using dst_hold_safe() andchecking if a reference was actually taken before setting the dst.[1] dmesg WARN_ON log and following refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge] __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ? br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ? vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge] __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix vlan tunnel dst null pointer dereferenceThis patch fixes a tunnel_dst null pointer dereference due to locklessaccess in the tunnel egress path. When deleting a vlan tunnel thetunnel_dst pointer is set to NULL without waiting a grace period (i.e.while it's still usable) and packets egressing are dereferencing itwithout checking. Use READ/WRITE_ONCE to annotate the lockless use oftunnel_id, use RCU for accessing tunnel_dst and make sure it is readonly once and checked in the egress path. The dst is already properly RCUprotected so we don't need to do anything fancy than to make suretunnel_id and tunnel_dst are read only once and checked in the egress path.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211-hwsim: fix late beacon hrtimer handlingThomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglxthat our handling of the hrtimer here is wrong: If the timer fireslate (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)then it tries to actually rearm the timer at the next deadline,which might be in the past already: 1 2 3 N N+1 | | | ... | | ^ intended to fire here (1) ^ next deadline here (2) ^ actually fired hereThe next time it fires, it's later, but will still try to schedulefor the next deadline (now 3), etc. until it catches up with N,but that might take a long time, causing stalls etc.Now, all of this is simulation, so we just have to fix it, butnote that the behaviour is wrong even per spec, since there's novalue then in sending all those beacons unaligned - they should bealigned to the TBTT (1, 2, 3, ... in the picture), and if we're abit (or a lot) late, then just resume at that point.Therefore, change the code to use hrtimer_forward_now() which willensure that the next firing of the timer would be at N+1 (in thepicture), i.e. the next interval point after the current time.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix abort logic in btrfs_replace_file_extentsError injection testing uncovered a case where we'd end up with acorrupt file system with a missing extent in the middle of a file. Thisoccurs because the if statement to decide if we should abort is wrong.The only way we would abort in this case is if we got a ret !=-EOPNOTSUPP and we called from the file clone code. However theprealloc code uses this path too. Instead we need to abort if there isan error, and the only error we _don't_ abort on is -EOPNOTSUPP and onlyif we came from the clone file code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Fix possible memory leak in ptp_clock_register()I got memory leak as follows when doing fault injection test:unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]When posix_clock_register() returns an error, the name allocatedin dev_set_name() will be leaked, the put_device() should be usedto give up the device reference, then the name will be freed inkobject_cleanup() and other memory will be freed in ptp_clock_release().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mxl111sf: change mutex_init() locationSyzbot reported, that mxl111sf_ctrl_msg() uses uninitializedmutex. The problem was in wrong mutex_init() location.Previous mutex_init(&state->msg_lock) call was in ->init() function, butdvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init()Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()internally we need to initialize state->msg_lock beforefrontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*devices, which will simply initiaize mutex.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: fix segfault in nfc_genl_dump_devices_doneWhen kmalloc in nfc_genl_dump_devices() fails thennfc_genl_dump_devices_done() segfaults as belowKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014Workqueue: events netlink_sock_destruct_workRIP: 0010:klist_iter_exit+0x26/0x80Call Trace:class_dev_iter_exit+0x15/0x20nfc_genl_dump_devices_done+0x3b/0x50genl_lock_done+0x84/0xd0netlink_sock_destruct+0x8f/0x270__sk_destruct+0x64/0x3b0sk_destruct+0xa8/0xd0__sk_free+0x2e8/0x3d0sk_free+0x51/0x90netlink_sock_destruct_work+0x1c/0x20process_one_work+0x411/0x710worker_thread+0x6fd/0xa80
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix a memory leak in 'host1x_remove()'Add a missing 'host1x_channel_list_free()' call in the remove function,as already done in the error handling path of the probe function.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0When walking through an inode extents, the ext4_ext_binsearch_idx() functionassumes that the extent header has been previously validated. However, thereare no checks that verify that the number of entries (eh->eh_entries) isnon-zero when depth is > 0. And this will lead to problems because theEXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:[ 135.245946] ------------[ cut here ]------------[ 135.247579] kernel BUG at fs/ext4/extents.c:2258![ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0[ 135.256475] Code:[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0[ 135.277952] Call Trace:[ 135.278635] [ 135.279247] ? preempt_count_add+0x6d/0xa0[ 135.280358] ? percpu_counter_add_batch+0x55/0xb0[ 135.281612] ? _raw_read_unlock+0x18/0x30[ 135.282704] ext4_map_blocks+0x294/0x5a0[ 135.283745] ? xa_load+0x6f/0xa0[ 135.284562] ext4_mpage_readpages+0x3d6/0x770[ 135.285646] read_pages+0x67/0x1d0[ 135.286492] ? folio_add_lru+0x51/0x80[ 135.287441] page_cache_ra_unbounded+0x124/0x170[ 135.288510] filemap_get_pages+0x23d/0x5a0[ 135.289457] ? path_openat+0xa72/0xdd0[ 135.290332] filemap_read+0xbf/0x300[ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40[ 135.292192] new_sync_read+0x103/0x170[ 135.293014] vfs_read+0x15d/0x180[ 135.293745] ksys_read+0xa1/0xe0[ 135.294461] do_syscall_64+0x3c/0x80[ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0This patch simply adds an extra check in __ext4_ext_check(), verifying thateh_entries is not 0 when eh_depth is > 0.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix hang during unmount when stopping a space reclaim workerOften when running generic/562 from fstests we can hang during unmount,resulting in a trace like this: Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0 Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530 Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140 Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30 Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0 Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170 Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0 Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120 Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30 Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs] Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0 Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160 Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0 Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0 Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40 Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90 Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0 Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 Sep 07 11:55:32 debian9 kernel: What happens is the following:1) The cleaner kthread tries to start a transaction to delete an unused block group, but the metadata reservation can not be satisfied right away, so a reservation ticket is created and it starts the async metadata reclaim task (fs_info->async_reclaim_work);2) Writeback for all the filler inodes with an i_size of 2K starts (generic/562 creates a lot of 2K files with the goal of filling metadata space). We try to create an inline extent for them, but we fail when trying to insert the inline extent with -ENOSPC (at cow_file_range_inline()) - since this is not critical, we fallback to non-inline mode (back to cow_file_range()), reserve extents---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()We don't currently validate that the values being set are within the rangewe advertised to userspace as being valid, do so and reject any valuesthat are out of range.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()While looking at one unrelated syzbot bug, I found the replay logicin __rtnl_newlink() to potentially trigger use-after-free.It is better to clear master_dev and m_ops inside the loop,in case we have to replay it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instructionThe illegal instruction turned out to be 'ldbrx' emitted forBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use ofthe same and implement an alternative approach for older processors.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix a memleak when uncloning an skb dst and its metadataWhen uncloning an skb dst and its associated metadata, a newdst+metadata is allocated and later replaces the old one in the skb.This is helpful to have a non-shared dst+metadata attached to a specificskb.The issue is the uncloned dst+metadata is initialized with a refcount of1, which is increased to 2 before attaching it to the skb. Whentun_dst_unclone returns, the dst+metadata is only referenced from asingle place (the skb) while its refcount is 2. Its refcount will neverdrop to 0 (when the skb is consumed), leading to a memory leak.Fix this by removing the call to dst_hold in tun_dst_unclone, as thedst+metadata refcount is already 1.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:swiotlb: fix info leak with DMA_FROM_DEVICEThe problem I'm addressing was discovered by the LTP test coveringcve-2018-1000204.A short description of what happens follows:1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device.2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO.3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV).4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer.5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails.One can argue that this is an swiotlb problem, because without swiotlbwe leak all zeros, and the swiotlb should be transparent in a sense thatit does not affect the outcome (if all other participants are wellbehaved).Copying the content of the original buffer into the swiotlb buffer isthe only way I can think of to make swiotlb transparent in suchscenarios. So let's do just that if in doubt, but allow the driverto tell us that the whole mapped buffer is going to be overwritten,in which case we can preserve the old behavior and avoid the performanceimpact of the extra bounce.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Fix preallocation discarding at indirect extent boundaryWhen preallocation extent is the first one in the extent block, thecode would corrupt extent tree header instead. Fix the problem and useudf_delete_aext() for deleting extent to avoid some code duplication.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix u8 overflowBy keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increasesmultiple times and eventually it will wrap around the maximum number(i.e., 255).This patch prevents this by adding a boundary check withL2CAP_MAX_CONF_RSPBtmon log:Bluetooth monitor ver 5.64= Note: Linux version 6.1.0-rc2 (x86_64) 0.264594= Note: Bluetooth subsystem version 2.22 0.264636@ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191= New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604@ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741= Open Index: 00:00:00:00:00:00 [hci0] 13.900426(...)> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............> ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......= bluetoothd: Bluetooth daemon 5.43 14.401828> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Initialize mailbox message for VF resetWhen a MAC address is not assigned to the VF, that portion of the messagesent to the VF is not set. The memory, however, is allocated from thestack meaning that information may be leaked to the VM. Initialize themessage buffer to 0 so that no information is passed to the VM in thiscase.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()The bounds checks in snd_soc_put_volsw_sx() are only being applied to thefirst channel, meaning it is possible to write out of bounds values to thesecond channel in stereo controls. Add appropriate checks.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtc: cmos: Fix event handler registration ordering issueBecause acpi_install_fixed_event_handler() enables the eventautomatically on success, it is incorrect to call it before thehandler routine passed to it is ready to handle events.Unfortunately, the rtc-cmos driver does exactly the incorrect thingby calling cmos_wake_setup(), which passes rtc_handler() toacpi_install_fixed_event_handler(), before cmos_do_probe(), becausertc_handler() uses dev_get_drvdata() to get to the cmos objectpointer and the driver data pointer is only populated incmos_do_probe().This leads to a NULL pointer dereference in rtc_handler() on bootif the RTC fixed event happens to be active at the init time.To address this issue, change the initialization ordering of thedriver so that cmos_wake_setup() is always called after a successfulcmos_do_probe() call.While at it, change cmos_pnp_probe() to call cmos_do_probe() afterthe initial if () statement used for computing the IRQ argument tobe passed to cmos_do_probe() which is cleaner than calling it ineach branch of that if () (local variable "irq" can be of type int,because it is passed to that function as an argument of type int).Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not checkACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger numberof systems, because previously it only affected systems withACPI_FADT_LOW_POWER_S0 set, but it is present regardless of thatcommit.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: Fix NULL sring after live migrationA NAPI is setup for each network sring to poll data to kernelThe sring with source host is destroyed before live migration andnew sring with target host is setup after live migration.The NAPI for the old sring is not deleted until setup new sringwith target host after migration. With busy_poll/busy_read enabled,the NAPI can be polled before got deleted when resume VM.BUG: unable to handle kernel NULL pointer dereference at0000000000000008IP: xennet_poll+0xae/0xd20PGD 0 P4D 0Oops: 0000 [#1] SMP PTICall Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6...RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900CR2: 0000000000000008---[ end trace f8601785b354351c ]---xen frontend should remove the NAPIs for the old srings before livemigration as the bond srings are destroyedThere is a tiny window between the srings are set to NULL andthe NAPIs are disabled, It is safe as the NAPI threads are stillfrozen at that time
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix not cleanup led when bt_init failsbt_init() calls bt_leds_init() to register led, but if it fails later,bt_leds_cleanup() is not called to unregister it.This can cause panic if the argument "bluetooth-power" in text is freedand then another led_trigger_register() tries to access it:BUG: unable to handle page fault for address: ffffffffc06d3bc0RIP: 0010:strcmp+0xc/0x30 Call Trace: led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()Kernel fault injection test reports null-ptr-deref as follows:BUG: kernel NULL pointer dereference, address: 0000000000000008RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114Call Trace: raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316ieee802154_if_add() allocates wpan_dev as netdev's private data, but notinit the list in struct wpan_dev. cfg802154_netdev_notifier_call() managethe list when device register/unregister, and may lead to null-ptr-deref.Use INIT_LIST_HEAD() on it to initialize it correctly.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: soc-pcm: Add NULL check in BE reparentingAdd NULL check in dpcm_be_reparent API, to handlekernel NULL pointer dereference error.The issue occurred in fuzzing test.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Check for null before removing sysfs attrsIf coretemp_add_core() gets an error then pdata->core_data[indx]is already NULL and has been kfreed. Don't pass that tosysfs_remove_group() as that will crash in sysfs_remove_group().[Shortened for readability][91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188[91855.165103] #PF: supervisor read access in kernel mode[91855.194506] #PF: error_code(0x0000) - not-present page[91855.224445] PGD 0 P4D 0[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI...[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80...[91855.796571] Call Trace:[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp][91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp][91855.871107] cpuhp_invoke_callback+0x105/0x4b0[91855.893432] cpuhp_thread_fun+0x8e/0x150...Fix this by checking for NULL first.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it after using to avoid refcount leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: fix null-ptr-deref while probe() failedI got a null-ptr-deref report as following when doing fault injection test:BUG: kernel NULL pointer dereference, address: 0000000000000058Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:klist_put+0x2d/0xd0Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0//probe path:phy_device_register() device_add()phy_connect phy_attach_direct() //set device driver probe() //it's failed, driver is not bound device_bind_driver() // probe failed, it's not called//remove path:phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev->drv is not NULL klist_remove() <- knode_driver is not added yet, cause null-ptr-derefIn phy_attach_direct(), after setting the 'dev->driver', probe() fails,device_bind_driver() is not called, so the knode_driver->n_klist is notset, then it causes null-ptr-deref in __device_release_driver() whiledeleting device. Fix this by setting dev->driver to NULL in the errorpath in phy_attach_direct().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e100: Fix possible use after free in e100_xmit_prepareIn e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, soe100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer willresend the skb. But the skb is already freed, which will cause UAF bugwhen the upper layer resends the skb.Remove the harmful free.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix error handling in iavf_init_module()The iavf_init_module() won't destroy workqueue when pci_register_driver()failed. Call destroy_workqueue() when pci_register_driver() failed toprevent the resource leak.Similar to the handling of u132_hcd_init in commit f276e002793c("usb: u132-hcd: fix resource leak")
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: Fix resource leak in ixgbevf_init_module()ixgbevf_init_module() won't destroy the workqueue created bycreate_singlethread_workqueue() when pci_register_driver() failed. Adddestroy_workqueue() in fail path to prevent the resource leak.Similar to the handling of u132_hcd_init in commit f276e002793c("usb: u132-hcd: fix resource leak")
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() failsSmatch report warning as follows:drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from listIf ibmpex_find_sensors() fails in ibmpex_register_bmc(), data willbe freed, but data->list will not be removed from driver_data.bmc_data,then list traversal may cause UAF.Fix by removeing it from driver_data.bmc_data before free().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Check for potential null return of kmalloc_array()As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference.Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()dev_name() was called with dev.parent as argument but without toNULL-check it before.Solve this by checking the pointer before the call to dev_name().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3: Fix GICR_CTLR.RWP pollingIt turns out that our polling of RWP is totally wrong when checkingfor it in the redistributors, as we test the *distributor* bit index,whereas it is a different bit number in the RDs... Oopsie boo.This is embarassing. Not only because it is wrong, but also becauseit took *8 years* to notice the blunder...Just fix the damn thing.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve overflow the qgroup limitWe use extent_changeset->bytes_changed in qgroup_reserve_data() to recordhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently thebytes_changed is set as "unsigned int", and it will overflow if we try tofallocate a range larger than 4GiB. The result is we reserve less bytesand eventually break the qgroup limit.Unlike regular buffered/direct write, which we use one changeset foreach ordered extent, which can never be larger than 256M. Forfallocate, we use one changeset for the whole range, thus it no longerrespects the 256M per extent limit, and caused the problem.The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNTWhen running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiBSince we have no control of how bytes_changed is used, it's better toset it to u64.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Fix use-after-free bug for mm structUnder certain conditions, such as MPI_Abort, the hfi1 cleanup code mayrepresent the last reference held on the task mm.hfi1_mmu_rb_unregister() then drops the last reference and the mm is freedbefore the final use in hfi1_release_user_pages(). A new task mayallocate the mm structure while it is still being used, resulting inproblems. One manifestation is corruption of the mmap_sem counter leadingto a hang in down_write(). Another is corruption of an mm struct that isin use by another task.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qede: confirm skb is allocated before usingqede_build_skb() assumes build_skb() always works and goes straightto skb_reserve(). However, build_skb() can fail under memory pressure.This results in a kernel panic because the skb to reserve is NULL.Add a check in case build_skb() failed to allocate and return NULL.The NULL return is handled correctly in callers to qede_build_skb().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix memory leak in ceph_readdir when note_last_dentry returns errorReset the last_readdir at the same time, and add a comment explainingwhy we don't free last_readdir when dir_emit returns false.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix inode reference leakage in ceph_get_snapdir()The ceph_get_inode() will search for or insert a new inode into thehash for the given vino, and return a reference to it. If new isnon-NULL, its reference is consumed.We should release the reference when in error handing cases.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix use after free in hci_send_aclThis fixes the following trace caused by receivingHCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del withoutfirst checking if conn->type is in fact AMP_LINK and in case it isdo properly cleanup upper layers with hci_disconn_cfm: ================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Free irq vectors in order for v3 HWIf the driver probe fails to request the channel IRQ or fatal IRQ, thedriver will free the IRQ vectors before freeing the IRQs in free_irq(),and this will cause a kernel BUG like this:------------[ cut here ]------------kernel BUG at drivers/pci/msi.c:369!Internal error: Oops - BUG: 0 [#1] PREEMPT SMPCall trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20---[ end trace b88990335b610c11 ]---So we use devm_add_action() to control the order in which we free thevectors.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req()In pm8001_chip_fw_flash_update_build(), ifpm8001_chip_fw_flash_update_build() fails, the struct fw_control_exallocated must be freed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix task leak in pm8001_send_abort_all()In pm8001_send_abort_all(), make sure to free the allocated sas taskif pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix memory leak[why]Resource release is needed on the error handling pathto prevent memory leak.[how]Fix this by adding kfree on the error handling path.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: fix null ptr deref on hci_sync_conn_complete_evtThis event is just specified for SCO and eSCO link types.On the reception of a HCI_Synchronous_Connection_Complete for a BDADDRof an existing LE connection, LE link type and a status that triggers thesecond case of the packet processing a NULL pointer dereference happens,as conn->link is NULL.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: properly check endpoint typeSyzbot reported warning in usb_submit_urb() which is caused by wrongendpoint type. We should check that in endpoint is actually present toprevent this warning.Found pipes are now saved to struct mcba_priv and code uses themdirectly instead of making pipes in place.Fail log:| usb 5-1: BOGUS urb xfer, pipe 3 != type 1| WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502| Modules linked in:| CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014| Workqueue: usb_hub_wq hub_event| RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502| ...| Call Trace:| | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline]| mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858| usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396| call_driver_probe drivers/base/dd.c:517 [inline]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: core: keep irq flags in device_pm_check_callbacks()The function device_pm_check_callbacks() can be called under the spinlock (in the reported case it happens from genpd_add_device() ->dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.However this function uncoditionally uses spin_lock_irq() /spin_unlock_irq(), thus not preserving the CPU flags. Use theirqsave/irqrestore instead.The backtrace for the reference:[ 2.752010] ------------[ cut here ]------------[ 2.756769] raw_local_irq_restore() called with IRQs enabled[ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50[ 2.772338] Modules linked in:[ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684[ 2.781384] Freeing initrd memory: 46024K[ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50[ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50[ 2.785846] sp : ffff80000805b7d0[ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002[ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800[ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00[ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff[ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7[ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8[ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0[ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0[ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000[ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000[ 2.889774] Call trace:[ 2.892290] warn_bogus_irq_restore+0x34/0x50[ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0[ 2.901690] genpd_unlock_spin+0x20/0x30[ 2.905724] genpd_add_device+0x100/0x2d0[ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c[ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190[ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0[ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30[ 2.929102] psci_dt_attach_cpu+0x24/0x90[ 2.933230] psci_cpuidle_probe+0x2d4/0x46c[ 2.937534] platform_probe+0x68/0xe0[ 2.941304] really_probe.part.0+0x9c/0x2fc[ 2.945605] __driver_probe_device+0x98/0x144[ 2.950085] driver_probe_device+0x44/0x15c[ 2.954385] __device_attach_driver+0xb8/0x120[ 2.958950] bus_for_each_drv+0x78/0xd0[ 2.962896] __device_attach+0xd8/0x180[ 2.966843] device_initial_probe+0x14/0x20[ 2.971144] bus_probe_device+0x9c/0xa4[ 2.975092] device_add+0x380/0x88c[ 2.978679] platform_device_add+0x114/0x234[ 2.983067] platform_device_register_full+0x100/0x190[ 2.988344] psci_idle_init+0x6c/0xb0[ 2.992113] do_one_initcall+0x74/0x3a0[ 2.996060] kernel_init_freeable+0x2fc/0x384[ 3.000543] kernel_init+0x28/0x130[ 3.004132] ret_from_fork+0x10/0x20[ 3.007817] irq event stamp: 319826[ 3.011404] hardirqs last enabled at (319825): [] __up_console_sem+0x78/0x84[ 3.020332] hardirqs last disabled at (319826): [] el1_dbg+0x24/0x8c[ 3.028458] softirqs last enabled at (318312): [] _stext+0x410/0x588[ 3.036678] softirqs last disabled at (318299): [] __irq_exit_rcu+0x158/0x174[ 3.045607] ---[ end trace 0000000000000000 ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bfq: fix use-after-free in bfq_dispatch_requestKASAN reports a use-after-free report when doing normal scsi-mq test[69832.239032] ==================================================================[69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0[69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155[69832.244656][69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8[69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[69832.249069] Workqueue: kblockd blk_mq_run_work_fn[69832.250022] Call Trace:[69832.250541] dump_stack+0x9b/0xce[69832.251232] ? bfq_dispatch_request+0x1045/0x44b0[69832.252243] print_address_description.constprop.6+0x3e/0x60[69832.253381] ? __cpuidle_text_end+0x5/0x5[69832.254211] ? vprintk_func+0x6b/0x120[69832.254994] ? bfq_dispatch_request+0x1045/0x44b0[69832.255952] ? bfq_dispatch_request+0x1045/0x44b0[69832.256914] kasan_report.cold.9+0x22/0x3a[69832.257753] ? bfq_dispatch_request+0x1045/0x44b0[69832.258755] check_memory_region+0x1c1/0x1e0[69832.260248] bfq_dispatch_request+0x1045/0x44b0[69832.261181] ? bfq_bfqq_expire+0x2440/0x2440[69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170[69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830[69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100[69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0[69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570[69832.267147] ? __switch_to+0x5f4/0xee0[69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140[69832.268946] __blk_mq_run_hw_queue+0xc0/0x270[69832.269840] blk_mq_run_work_fn+0x51/0x60[69832.278170] process_one_work+0x6d4/0xfe0[69832.278984] worker_thread+0x91/0xc80[69832.279726] ? __kthread_parkme+0xb0/0x110[69832.280554] ? process_one_work+0xfe0/0xfe0[69832.281414] kthread+0x32d/0x3f0[69832.282082] ? kthread_park+0x170/0x170[69832.282849] ret_from_fork+0x1f/0x30[69832.283573][69832.283886] Allocated by task 7725:[69832.284599] kasan_save_stack+0x19/0x40[69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0[69832.286350] kmem_cache_alloc_node+0x13f/0x460[69832.287237] bfq_get_queue+0x3d4/0x1140[69832.287993] bfq_get_bfqq_handle_split+0x103/0x510[69832.289015] bfq_init_rq+0x337/0x2d50[69832.289749] bfq_insert_requests+0x304/0x4e10[69832.290634] blk_mq_sched_insert_requests+0x13e/0x390[69832.291629] blk_mq_flush_plug_list+0x4b4/0x760[69832.292538] blk_flush_plug_list+0x2c5/0x480[69832.293392] io_schedule_prepare+0xb2/0xd0[69832.294209] io_schedule_timeout+0x13/0x80[69832.295014] wait_for_common_io.constprop.1+0x13c/0x270[69832.296137] submit_bio_wait+0x103/0x1a0[69832.296932] blkdev_issue_discard+0xe6/0x160[69832.297794] blk_ioctl_discard+0x219/0x290[69832.298614] blkdev_common_ioctl+0x50a/0x1750[69832.304715] blkdev_ioctl+0x470/0x600[69832.305474] block_ioctl+0xde/0x120[69832.306232] vfs_ioctl+0x6c/0xc0[69832.306877] __se_sys_ioctl+0x90/0xa0[69832.307629] do_syscall_64+0x2d/0x40[69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9[69832.309382][69832.309701] Freed by task 155:[69832.310328] kasan_save_stack+0x19/0x40[69832.311121] kasan_set_track+0x1c/0x30[69832.311868] kasan_set_free_info+0x1b/0x30[69832.312699] __kasan_slab_free+0x111/0x160[69832.313524] kmem_cache_free+0x94/0x460[69832.314367] bfq_put_queue+0x582/0x940[69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0[69832.317275] bfq_bfqq_expire+0xb27/0x2440[69832.318084] bfq_dispatch_request+0x697/0x44b0[69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830[69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0[69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140[69832.322225] __blk_mq_run_hw_queue+0xc0/0x270[69832.323114] blk_mq_run_work_fn+0x51/0x6---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memstick/mspro_block: fix handling of read-only devicesUse set_disk_ro to propagate the read-only state to the block layerinstead of checking for it in ->open and leaking a reference in caseof a read-only device.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add vlan list lock to protect vlan listWhen adding port base VLAN, vf VLAN need to remove from HW and modifythe vlan state in vf VLAN list as false. If the periodicity task isfreeing the same node, it may cause "use after free" error.This patch adds a vlan list lock to protect the vlan list.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_regionThe device_node pointer is returned by of_parse_phandle() orof_get_child_by_name() with refcount incremented.We should use of_node_put() on it when done.This function only call of_node_put(node) when of_address_to_resourcesucceeds, missing error cases.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmemmemory"), we could get a resource allocated during boot viaalloc_resource(). And it's required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: fix race between xmit and resetThere is a race between reset and the transmit paths that can lead toibmvnic_xmit() accessing an scrq after it has been freed in the resetpath. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2cThe immediate cause of the crash is the access of tx_scrq in the followingsnippet during a reset, where the tx_scrq can be either NULL or an addressthat will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... }But beyond that, the call to ibmvnic_xmit() itself is not safe during areset and the reset path attempts to avoid this by stopping the queue inibmvnic_cleanup(). However just after the queue was stopped, an in-flightibmvnic_complete_tx() could have restarted the queue even as the reset isprogressing.Since the queue was restarted we could get a call to ibmvnic_xmit() whichcan then access the bad tx_scrq (or other fields).We cannot however simply have ibmvnic_complete_tx() check the ->resettingbit and skip starting the queue. This can race at the "back-end" of a goodreset which just restarted the queue but has not cleared the ->resettingbit yet. If we skip restarting the queue due to ->resetting being true,the queue would remain stopped indefinitely potentially leading to transmittimeouts.IOW ->resetting is too broad for this purpose. Instead use a new flagthat indicates whether or not the queues are active. Only the open/reset paths control when the queues are active. ibmvnic_complete_tx()and others wake up the queue only if the queue is marked active.So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue();To ensure that ->tx_queues_active and state of the queues are consistent,we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix more uncharged while msg has more_dataIn tcp_bpf_send_verdict(), if msg has more data aftertcp_bpf_sendmsg_redir():tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_allocThe msg->sg.size(11000) has been uncharged twice, to fix we can charge theremaining msg->sg.size before goto more data.This issue can cause the following info:WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix double uncharge the mem of sk_msgIf tcp_bpf_sendmsg is running during a tear down operation, psock may befreed.tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free()The mem of msg has been uncharged in tcp_bpf_send_verdict() bysk_msg_return(), and would be uncharged by sk_msg_free() again. When psockis null, we can simply returning an error code, this would then triggerthe sk_msg_free_nocharge in the error path of __SK_REDIRECT and would havethe side effect of throwing an error up to user space. This would be aslight change in behavior from user side but would look the same as anerror if the redirect on the socket threw an error.This issue can cause the following info:WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is fullIf tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partialmemory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size isgreater than osize after sk_msg_alloc(), memleak occurs. To fix we usesk_msg_trim() to release the allocated memory, then goto wait for memory.Other call paths of sk_msg_alloc() have the similar issue, such astls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),as Cong Wang suggested.This issue can cause the following info:WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_initThe reference counting issue happens in several error handling pathson a refcounted object "nc->dmac". In these paths, the function simplyreturns the error code, forgetting to balance the reference count of"nc->dmac", increased earlier by dma_request_channel(), which maycause refcount leaks.Fix it by decrementing the refcount of specific object in those errorpaths.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix reference leak in tegra_dsi_ganged_probeThe reference taken by 'of_find_device_by_node()' must be released whennot needed anymore. Add put_device() call to fix this.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dax: make sure inodes are flushed before destroy cacheA bug can be triggered by following command$ modprobe nd_pmem && modprobe -r nd_pmem[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)[ 10.062433] Call Trace:[ 10.062673] dump_stack_lvl+0x34/0x44[ 10.062865] slab_err+0x90/0xd0[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0[ 10.063848] kmem_cache_destroy+0x4a/0x110[ 10.064058] __x64_sys_delete_module+0x265/0x300This is caused by dax_fs_exit() not flushing inodes before destroy cache.To fix this issue, call rcu_barrier() before destroy cache.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()is assigned to mode and is passed to drm_mode_probed_add() directly afterthat. drm_mode_probed_add() passes &mode->head to list_add_tail(), andthere is a dereference of it in list_add_tail() without recoveries, whichcould lead to NULL pointer dereference on failure ofamdgpu_dm_create_common_mode().Fix this by adding a NULL check of mode.This bug was found by a static analyzer.Builds with 'make allyesconfig' show no new warnings,and our static analyzer no longer warns about this code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath9k_htc: fix uninit value bugsSyzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missingfield initialization.In htc_connect_service() svc_meta_len and pad are not initialized. Basedon code it looks like in current skb there is no service data, so simplyinitialize svc_meta_len to 0.htc_issue_send() does not initialize htc_frame_hdr::control array. Basedon firmware code, it will initialize it by itself, so simply zero wholearray to make KMSAN happyFail logs:BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275...Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258...Bytes 4-7 of 18 are uninitializedMemory access of size 18 starts at ffff888027377e00BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275...Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258...Bytes 16-17 of 18 are uninitializedMemory access of size 18 starts at ffff888027377e00
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUEDIf the callback 'start_streaming' fails, then allqueued buffers in the driver should be returned withstate 'VB2_BUF_STATE_QUEUED'. Currently, they arereturned with 'VB2_BUF_STATE_ERROR' which is wrong.Fix this. This also fixes the warning:[ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common][ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6[ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14[ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT)[ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common][ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common][ 65.592395] sp : ffff800012bc3ad0[ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8[ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612[ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0[ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff[ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78[ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce[ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228[ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78[ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880[ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0[ 65.598940] Call trace:[ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common][ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common][ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2][ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2][ 65.601103] v4l_streamon+0x3c/0x50 [videodev][ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev][ 65.601977] video_usercopy+0x320/0x828 [videodev][ 65.602419] video_ioctl2+0x3c/0x58 [videodev][ 65.602830] v4l2_ioctl+0x60/0x90 [videodev][ 65.603227] __arm64_sys_ioctl+0xa8/0xe0[ 65.603576] invoke_syscall+0x54/0x118[ 65.603911] el0_svc_common.constprop.3+0x84/0x100[ 65.604332] do_el0_svc+0x34/0xa0[ 65.604625] el0_svc+0x1c/0x50[ 65.604897] el0t_64_sync_handler+0x88/0xb0[ 65.605264] el0t_64_sync+0x16c/0x170[ 65.605587] ---[ end trace 578e0ba07742170d ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transactionAV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:firewire-lib: Add support for deferred transaction") while 'deferrable'flag can be uninitialized for non-control/notify AV/C transactions.UBSAN reports it:kernel: ================================================================================kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9kernel: load of value 158 is not a valid value for type '_Bool'kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntukernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019kernel: Call Trace:kernel: kernel: show_stack+0x52/0x58kernel: dump_stack_lvl+0x4a/0x5fkernel: dump_stack+0x10/0x12kernel: ubsan_epilogue+0x9/0x45kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]kernel: fcp_response+0x28/0x30 [snd_firewire_lib]kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]kernel: tasklet_action_common.constprop.0+0xea/0xf0kernel: tasklet_action+0x22/0x30kernel: __do_softirq+0xd9/0x2e3kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0kernel: do_softirq+0x75/0xa0kernel: kernel: kernel: __local_bh_enable_ip+0x50/0x60kernel: irq_forced_thread_fn+0x7e/0x90kernel: irq_thread+0xba/0x190kernel: ? irq_thread_fn+0x60/0x60kernel: kthread+0x11e/0x140kernel: ? irq_thread_check_affinity+0xf0/0xf0kernel: ? set_kthread_struct+0x50/0x50kernel: ret_from_fork+0x22/0x30kernel: kernel: ================================================================================This commit fixes the bug. The bug has no disadvantage for the non-control/notify AV/C transactions since the flag has an effect for AV/Cresponse with INTERIM (0x0f) status which is not used for the transactionsin AV/C general specification.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: usb: go7007: s2250-board: fix leak in probe()Call i2c_unregister_device(audio) on this error path.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_locksyzbot caught a potential deadlock between the PCMruntime->buffer_mutex and the mm->mmap_lock. It was brought by therecent fix to cover the racy read/write and other ioctls, and in thatcommit, I overlooked a (hopefully only) corner case that may take therevert lock, namely, the OSS mmap. The OSS mmap operationexceptionally allows to re-configure the parameters inside the OSSmmap syscall, where mm->mmap_mutex is already held. Meanwhile, thecopy_from/to_user calls at read/write operations also take themm->mmap_lock internally, hence it may lead to a AB/BA deadlock.A similar problem was already seen in the past and we fixed it with arefcount (in commit b248371628aa). The former fix covered only thecall paths with OSS read/write and OSS ioctls, while we need to coverthe concurrent access via both ALSA and OSS APIs now.This patch addresses the problem above by replacing the buffer_mutexlock in the read/write operations with a refcount similar as we'veused for OSS. The new field, runtime->buffer_accessing, keeps thenumber of concurrent read/write operations. Unlike the formerbuffer_mutex protection, this protects only around thecopy_from/to_user() calls; the other codes are basically protected bythe PCM stream lock. The refcount can be a negative, meaning blockedby the ioctls. If a negative value is seen, the read/write abortswith -EBUSY. In the ioctl side, OTOH, they check this refcount, too,and set to a negative value for blocking unless it's already beingaccessed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: oss: Fix PCM OSS buffer allocation overflowWe've got syzbot reports hitting INT_MAX overflow at vmalloc()allocation that is called from snd_pcm_plug_alloc(). Although weapply the restrictions to input parameters, it's based only on thehw_params of the underlying PCM device. Since the PCM OSS layerallocates a temporary buffer for the data conversion, the size maybecome unexpectedly large when more channels or higher rates is given;in the reported case, it went over INT_MAX, hence it hits WARN_ON().This patch is an attempt to avoid such an overflow and an allocationfor too large buffers. First off, it adds the limit of 1MB as theupper bound for period bytes. This must be large enough for all usecases, and we really don't want to handle a larger temporary bufferthan this size. The size check is performed at two places, where theoriginal period bytes is calculated and where the plugin buffer sizeis calculated.In addition, the driver uses array_size() and array3_size() formultiplications to catch overflows for the converted period size andbuffer bytes.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check if modulo is 0 before dividing.[How & Why]If a value of 0 is read, then this will cause a divide-by-0 panic.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:extcon: Modify extcon device to be created after driver data is setCurrently, someone can invoke the sysfs such as state_show()intermittently before dev_set_drvdata() is done.And it can be a cause of kernel Oops because of edev is Null at that time.So modified the driver registration to after setting drviver data.- Oops's backtrace.Backtrace:[] (state_show) from [] (dev_attr_show)[] (dev_attr_show) from [] (sysfs_kf_seq_show)[] (sysfs_kf_seq_show) from [] (kernfs_seq_show)[] (kernfs_seq_show) from [] (seq_read)[] (seq_read) from [] (kernfs_fop_read)[] (kernfs_fop_read) from [] (__vfs_read)[] (__vfs_read) from [] (vfs_read)[] (vfs_read) from [] (ksys_read)[] (ksys_read) from [] (sys_read)[] (sys_read) from [] (__sys_trace_return)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data typeIn zynqmp_dma_alloc/free_chan_resources functions there is apotential overflow in the below expressions.dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL);dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p);The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Thoughthis overflow condition is not observed but it is a potential problemin the case of 32-bit multiplication. Hence fix it by changing thedesc_size data type to size_t.In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro indma_alloc_coherent API argument.Addresses-Coverity: Event overflow_before_widen.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add accessors to read/set tp->snd_cwndWe had various bugs over the years with codebreaking the assumption that tp->snd_cwnd is greaterthan zero.Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) addedin commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")can trigger, and without a repro we would have to spendconsiderable time finding the bug.Instead of complaining too late, we want to catch whereand when tp->snd_cwnd is set to an illegal value.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtl818x: Prevent using not initialized queuesUsing not existing queues can panic the kernel with rtl8180/rtl8185 cards.Ignore the skb priority for those cards, they only have one tx queue. PierreAsselin (pa@panix.com) reported the kernel crash in the Gentoo forum:https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.htmlHe also confirmed that this patch fixes the issue. In summary this happened:After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a"divide error: 0000" when connecting to an AP. Control port tx now tries touse IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in2.10.Since only the rtl8187se part of the driver supports QoS, the priorityof the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185cards.rtl8180 is then unconditionally reading out the priority and finally crashes ondrivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without thispatch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never gotinitialized.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handlingError paths do not free previously allocated memory. Add devm_kfree() tothose failure paths.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix a data-race in unix_dgram_peer_wake_me().unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'slock held and check if its receive queue is full. Here we need touse unix_recvq_full_lockless() instead of unix_recvq_full(), otherwiseKCSAN will report a data-race.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: xfrm: unexport __init-annotated xfrm4_protocol_init()EXPORT_SYMBOL and __init is a bad combination because the .init.textsection is freed up after the initialization. Hence, modules cannotuse symbols annotated __init. The access to a freed symbol may end upwith kernel panic.modpost used to detect it, but it has been broken for a decade.Recently, I fixed modpost so it started to warn it again, then thisshowed up in linux-next builds.There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOLI chose the latter for this case because the only in-tree call-site,net/ipv4/xfrm4_policy.c is never compiled as modular.(CONFIG_XFRM is boolean)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: altera: Fix refcount leak in altera_tse_mdio_createEvery iteration of for_each_child_of_node() decrementsthe reference count of the previous node.When break from a for_each_child_of_node() loop,we need to explicitly call of_node_put() on the child node whennot need anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_registerof_get_child_by_name() returns a node pointer with refcountincremented, we should use of_node_put() on it when done.mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().We don't need the device node after it.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handlekobject_init_and_add() takes reference even when it fails.According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.Fix this issue by calling kobject_put().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix deadlock in __device_attachIn __device_attach function, The lock holding logic is as follows:...__device_attachdevice_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev)As shown above, when it is allowed to do async probes, because ofout of memory or work limit, async work is not allowed, to dosync execute instead. it will lead to A-A deadlock because of__device_attach_async_helper getting lock dev.To fix the deadlock, move the async_schedule_dev outside device_lock,as we can see, in async_schedule_node_domain, the parameter ofqueue_work_node is system_unbound_wq, so it can accept concurrentoperations. which will also not change the code logic, and willnot lead to deadlock.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_rtx_synack() can be called from process contextLaurent reported the enclosed report [1]This bug triggers with following coditions:0) Kernel built with CONFIG_DEBUG_PREEMPT=y1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one.2) A socket operation on this socket goes through lock_sock() release_sock() dance.3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog.4) At release_sock() time, the socket backlog is processed while in process context.5) A SYNACK packet is cooked in response of the SYN retransmit.6) -> tcp_rtx_synack() is called in process context.Before blamed commit, tcp_rtx_synack() was always called from BH handler,from a timer handler.Fix this by using TCP_INC_STATS() & NET_INC_STATS()which do not assume caller is in non preemptible context.[1]BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180caller is tcp_rtx_synack.part.0+0x36/0xc0CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: rockchip: Fix refcount leak in rockchip_grf_initof_find_matching_node_and_match returns a node pointer with refcountincremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver: base: fix UAF when driver_attach failedWhen driver_attach(drv); failed, the driver_private will be freed.But it has been added to the bus, which caused a UAF.To fix it, we need to delete it from the bus when failed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: ubi_create_volume: Fix use-after-free when volume creation failedThere is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'serror handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tblout_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAFFix it by removing redundant 'eba_tbl' releasing.Fetch a reproducer in [Link].
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macsec: fix UAF bug for real_devCreate a new macsec device but not get reference to real_dev. That cannot ensure that real_dev is freed after macsec. That will trigger theUAF bug for real_dev as following:==================================================================BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), wecan add dev_hold_track() in macsec_dev_init() and dev_put_track() inmacsec_free_netdev() to fix the problem.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:um: Fix out-of-bounds read in LDT setupsyscall_stub_data() expects the data_count parameter to be the number oflongs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qmp: fix reset-controller leak on probe errorsMake sure to release the lane reset controller in case of a late probeerror (e.g. probe deferral).Note that due to the reset controller being defined in devicetree in"lane" child nodes, devm_reset_control_get_exclusive() cannot be useddirectly.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qmp: fix struct clk leak on probe errorsMake sure to release the pipe clock reference in case of a late probeerror (e.g. probe deferral).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Fix potential integer multiplication overflow errorsWhen multiplying of different types, an overflow is possible even whenstoring the result in a larger type. This is because the conversion isdone after the multiplication. So arithmetic overflow and thus inincorrect value is possible.Correct an instance of this in the inter packet delay calculation. Fix byensuring one of the operands is u64 which will promote the other to u64 aswell ensuring no overflow.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bfq: Make sure bfqg for which we are queueing requests is onlineBios queued into BFQ IO scheduler can be associated with a cgroup thatwas already offlined. This may then cause insertion of this bfq_groupinto a service tree. But this bfq_group will get freed as soon as lastbio associated with it is completed leading to use after free issues forservice tree users. Fix the problem by making sure we always operate ononline bfq_group. If the bfq_group associated with the bio is notonline, we pick the first online parent.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix use-after-free in chanctx codeIn ieee80211_vif_use_reserved_context(), when we have anold context and the new context's replace_state is set toIEEE80211_CHANCTX_REPLACE_NONE, we free the old contextin ieee80211_vif_use_reserved_reassign(). Therefore, wecannot check the old_ctx anymore, so we should set it toNULL after this point.However, since the new_ctx replace state is clearly notIEEE80211_CHANCTX_REPLACES_OTHER, we're not going to doanything else in this function and can just return toavoid accessing the freed old_ctx.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Prevent use of lock before it is initializedIf there is a failure during probe of hfi1 before the sdma_map_lock isinitialized, the call to hfi1_free_devdata() will attempt to use a lockthat has not been initialized. If the locking correctness validator is onthen an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0The use of sdma_map_lock in sdma_clean() is for freeing the sdma_mapmemory, and sdma_map is not allocated/initialized until aftersdma_map_lock has been initialized. This code only needs to be run ifsdma_map is not NULL, and so checking for that condition will avoid tryingto use the lock before it is initialized.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: fix deadlock caused by calling printk() under tty_port->lockpty_write() invokes kmalloc() which may invoke a normal printk() to printfailure message. This can cause a deadlock in the scenario reported bysyz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner);As commit dbdda842fe96 ("printk: Add console owner and waiter logic toload balance console writes") said, such deadlock can be prevented byusing printk_deferred() in kmalloc() (which is invoked in the sectionguarded by the port->lock). But there are too many printk() on thekmalloc() path, and kmalloc() can be called from anywhere, so changingprintk() to printk_deferred() is too complicated and inelegant.Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), sothat printk() will not be called, and this deadlock problem can beavoided.Syzbot reported the following lockdep error:======================================================WARNING: possible circular locking dependency detected5.4.143-00237-g08ccc19a-dirty #10 Not tainted------------------------------------------------------syz-executor.4/29420 is trying to acquire lock:ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023but task is already holding lock:ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...]-> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241-> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers/base/node.c: fix compaction sysfs file leakCompaction sysfs file is created via compaction_register_node inregister_node. But we forgot to remove it in unregister_node. Thuscompaction sysfs file is leaked. Using compaction_unregister_node to fixthis issue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:module: fix [e_shstrndx].sh_size=0 OOB accessIt is trivial to craft a module to trigger OOB access in this line: if (info->secstrings[strhdr->sh_size - 1] != '\0') {BUG: unable to handle page fault for address: ffffc90000aa0fffPGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014RIP: 0010:load_module+0x19b/0x2391[rebased patch onto modules-next]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources()It will cause null-ptr-deref when using 'res', if platform_get_resource()returns NULL, so move using 'res' after devm_ioremap_resource() thatwill check it to avoid null-ptr-deref.And use devm_platform_get_and_ioremap_resource() to simplify code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: rk3399_dmc: Disable edev on remove()Otherwise we hit an unablanced enable-count when unbinding the DFIdevice:[ 1279.659119] ------------[ cut here ]------------[ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c...[ 1279.659352] Hardware name: Google Kevin (DT)[ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--)[ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c[ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28...[ 1279.659571] Call trace:[ 1279.659582] devfreq_event_remove_edev+0x84/0x8c[ 1279.659590] devm_devfreq_event_release+0x1c/0x28[ 1279.659602] release_nodes+0x1cc/0x244[ 1279.659611] devres_release_all+0x44/0x60[ 1279.659621] device_release_driver_internal+0x11c/0x1ac[ 1279.659629] device_driver_detach+0x20/0x2c[ 1279.659641] unbind_store+0x7c/0xb0[ 1279.659650] drv_attr_store+0x2c/0x40[ 1279.659663] sysfs_kf_write+0x44/0x58[ 1279.659672] kernfs_fop_write_iter+0xf4/0x190[ 1279.659684] vfs_write+0x2b0/0x2e4[ 1279.659693] ksys_write+0x80/0xec[ 1279.659701] __arm64_sys_write+0x24/0x30[ 1279.659714] el0_svc_common+0xf0/0x1d8[ 1279.659724] do_el0_svc_compat+0x28/0x3c[ 1279.659738] el0_svc_compat+0x10/0x1c[ 1279.659746] el0_sync_compat_handler+0xa8/0xcc[ 1279.659758] el0_sync_compat+0x188/0x1c0[ 1279.659768] ---[ end trace cec200e5094155b4 ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_boneeds to be put when msm_gem_get_and_pin_iova fails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: micrel: Allow probing without .driver_dataCurrently, if the .probe element is present in the phy_driver structureand the .driver_data is not, a NULL pointer dereference happens.Allow passing .probe without .driver_data by inserting NULL checksfor priv->type.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeoutConnecting the same socket twice consecutively in sco_sock_connect()could lead to a race condition where two sco_conn objects are createdbut only one is associated with the socket. If the socket is closedbefore the SCO connection is established, the timer associated with thedangling sco_conn object won't be canceled. As the sock object is beingfreed, the use-after-free problem happens when the timer callbackfunction sco_sock_timeout() accesses the socket. Here's the call trace:dump_stack+0x107/0x163? refcount_inc+0x1c/print_address_description.constprop.0+0x1c/0x47e? refcount_inc+0x1c/0x7bkasan_report+0x13a/0x173? refcount_inc+0x1c/0x7bcheck_memory_region+0x132/0x139refcount_inc+0x1c/0x7bsco_sock_timeout+0xb2/0x1baprocess_one_work+0x739/0xbd1? cancel_delayed_work+0x13f/0x13f? __raw_spin_lock_init+0xf0/0xf0? to_kthread+0x59/0x85worker_thread+0x593/0x70ekthread+0x346/0x35a? drain_workqueue+0x31a/0x31a? kthread_bind+0x4b/0x4bret_from_fork+0x1f/0x30
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_initSyzbot reported that -1 is used as array index. The problem was inmissing validation check.hdw->unit_number is initialized with -1 and then if init table walk failsthis value remains unchanged. Since code blindly uses this member forarray indexing adding sanity check is the easiest fix for that.hdw->workpoll initialization moved upper to prevent warning in__flush_work.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detectedThere is a possibility for mdp5_get_global_state to return-EDEADLK when acquiring the modeset lock, but currently global_state inmdp5_mixer_release doesn't check for if an error is returned.To avoid a NULL dereference error, let's have mdp5_mixer_releasecheck if an error is returned and propagate that error.Patchwork: https://patchwork.freedesktop.org/patch/485181/
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resumeBUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16cPatchwork: https://patchwork.freedesktop.org/patch/483255/[DB: fixed Fixes tag]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detectedmdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiringthe modeset lock, but currently mdp5_pipe_release doesn't check for ifan error is returned. Because of this, there is a possibility ofmdp5_pipe_release hitting a NULL dereference error.To avoid this, let's have mdp5_pipe_release check ifmdp5_get_global_state returns an error and propogate that error.Changes since v1:- Separated declaration and initialization of *new_state to avoid compiler warning- Fixed some spelling mistakes in commit messageChanges since v2:- Return 0 in case where hwpipe is NULL as this is considered normal behavior- Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_releasePatchwork: https://patchwork.freedesktop.org/patch/485179/
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()It will cause null-ptr-deref in resource_size(), if platform_get_resource()returns NULL, move calling resource_size() after devm_ioremap_resource() thatwill check 'res' to avoid null-ptr-deref.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/hdmi: check return value after calling platform_get_resource_byname()It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,we need check the return value.Patchwork: https://patchwork.freedesktop.org/patch/482992/
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: remove two BUG() from skb_checksum_help()I have a syzbot report that managed to get a crash in skb_checksum_help()If syzbot can trigger these BUG(), it makes sense to replacethem with more friendly WARN_ON_ONCE() since skb_checksum_help()can instead return an error code.Note that syzbot will still crash there, until real bug is fixed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyixThe "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need toensure that it is within the bitmap.drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept()error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: NULL out the dev->rfkill to prevent UAFCommit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")assumes the device_is_registered() in function nfc_dev_up() will helpto check when the rfkill is unregistered. However, this check onlytake effect when device_del(&dev->dev) is done in nfc_unregister_device().Hence, the rfkill object is still possible be dereferenced.The crash trace in latest kernel (5.18-rc2):[ 68.760105] ==================================================================[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313[ 68.760756][ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 68.760756] Call Trace:[ 68.760756] [ 68.760756] dump_stack_lvl+0x57/0x7d[ 68.760756] print_report.cold+0x5e/0x5db[ 68.760756] ? __lock_acquire+0x3ec1/0x6750[ 68.760756] kasan_report+0xbe/0x1c0[ 68.760756] ? __lock_acquire+0x3ec1/0x6750[ 68.760756] __lock_acquire+0x3ec1/0x6750[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 68.760756] ? register_lock_class+0x18d0/0x18d0[ 68.760756] lock_acquire+0x1ac/0x4f0[ 68.760756] ? rfkill_blocked+0xe/0x60[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0[ 68.760756] ? nla_get_range_signed+0x540/0x540[ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50[ 68.760756] _raw_spin_lock_irqsave+0x39/0x50[ 68.760756] ? rfkill_blocked+0xe/0x60[ 68.760756] rfkill_blocked+0xe/0x60[ 68.760756] nfc_dev_up+0x84/0x260[ 68.760756] nfc_genl_dev_up+0x90/0xe0[ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0[ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230[ 68.760756] ? security_capable+0x51/0x90[ 68.760756] genl_rcv_msg+0x280/0x500[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0[ 68.760756] ? lock_acquire+0x1ac/0x4f0[ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 68.760756] netlink_rcv_skb+0x11b/0x340[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0[ 68.760756] ? netlink_ack+0x9c0/0x9c0[ 68.760756] ? netlink_deliver_tap+0x136/0xb00[ 68.760756] genl_rcv+0x1f/0x30[ 68.760756] netlink_unicast+0x430/0x710[ 68.760756] ? memset+0x20/0x40[ 68.760756] ? netlink_attachskb+0x740/0x740[ 68.760756] ? __build_skb_around+0x1f4/0x2a0[ 68.760756] netlink_sendmsg+0x75d/0xc00[ 68.760756] ? netlink_unicast+0x710/0x710[ 68.760756] ? netlink_unicast+0x710/0x710[ 68.760756] sock_sendmsg+0xdf/0x110[ 68.760756] __sys_sendto+0x19e/0x270[ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0[ 68.760756] ? fd_install+0x178/0x4c0[ 68.760756] ? fd_install+0x195/0x4c0[ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0[ 68.760756] __x64_sys_sendto+0xd8/0x1b0[ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130[ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50[ 68.760756] do_syscall_64+0x3b/0x90[ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 68.760756] RIP: 0033:0x7f67fb50e6b3...[ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c[ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3[ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003[ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c[ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e[ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003[ 68.760756] [ 68.760756][ 68.760756] Allocated by task 279:[ 68.760756] kasan_save_stack+0x1e/0x40[---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: Use kobject release() method to free dbs_dataThe struct dbs_data embeds a struct gov_attr_set andthe struct gov_attr_set embeds a kobject. Since every kobject must havea release() method and we can't use kfree() to free it directly,so introduce cpufreq_dbs_data_release() to release the dbs_data viathe kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4[ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath10k: skip ath10k_halt during suspend for driver state RESTARTINGDouble free crash is observed when FW recovery(caused by wmitimeout/crash) is followed by immediate suspend event. The FW recoveryis triggered by ath10k_core_restart() which calls driver clean up viaath10k_halt(). When the suspend event occurs between the FW recovery,the restart worker thread is put into frozen state until suspend completes.The suspend event triggers ath10k_stop() which again triggers ath10k_halt()The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to becalled twice(Note: ath10k_htt_rx_alloc was not called by restart workerthread because of its frozen state), causing the crash.To fix this, during the suspend flow, skip call to ath10k_halt() inath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING.Also, for driver state ATH10K_STATE_RESTARTING, callath10k_wait_for_suspend() in ath10k_stop(). This is because call toath10k_wait_for_suspend() is skipped later in[ath10k_halt() > ath10k_core_stop()] for the driver stateATH10K_STATE_RESTARTING.The frozen restart worker thread will be cancelled during resume when thedevice comes out of suspend.Below is the crash stack for reference:[ 428.469167] ------------[ cut here ]------------[ 428.469180] kernel BUG at mm/slub.c:4150![ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 428.469219] Workqueue: events_unbound async_run_entry_fn[ 428.469230] RIP: 0010:kfree+0x319/0x31b[ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246[ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000[ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000[ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000[ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 428.469285] Call Trace:[ 428.469295] ? dma_free_attrs+0x5f/0x7d[ 428.469320] ath10k_core_stop+0x5b/0x6f[ 428.469336] ath10k_halt+0x126/0x177[ 428.469352] ath10k_stop+0x41/0x7e[ 428.469387] drv_stop+0x88/0x10e[ 428.469410] __ieee80211_suspend+0x297/0x411[ 428.469441] rdev_suspend+0x6e/0xd0[ 428.469462] wiphy_suspend+0xb1/0x105[ 428.469483] ? name_show+0x2d/0x2d[ 428.469490] dpm_run_callback+0x8c/0x126[ 428.469511] ? name_show+0x2d/0x2d[ 428.469517] __device_suspend+0x2e7/0x41b[ 428.469523] async_suspend+0x1f/0x93[ 428.469529] async_run_entry_fn+0x3d/0xd1[ 428.469535] process_one_work+0x1b1/0x329[ 428.469541] worker_thread+0x213/0x372[ 428.469547] kthread+0x150/0x15f[ 428.469552] ? pr_cont_work+0x58/0x58[ 428.469558] ? kthread_blkcg+0x31/0x31Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: Fix the error handling in cx23885_initdev()When the driver fails to call the dma_set_mask(), the driver will getthe following splat:[ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240[ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590[ 55.856822] Call Trace:[ 55.860327] __process_removed_driver+0x3c/0x240[ 55.861347] bus_for_each_dev+0x102/0x160[ 55.861681] i2c_del_driver+0x2f/0x50This is because the driver has initialized the i2c related resourcesin cx23885_dev_setup() but not released them in error handling, fix thisbug by modifying the error path that jumps after failing to call thedma_set_mask().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx25821: Fix the warning when removing the moduleWhen removing the module, we will get the following warning:[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0[ 14.759589] Call Trace:[ 14.759792] [ 14.759975] unregister_irq_proc+0x14c/0x170[ 14.760340] irq_free_descs+0x94/0xe0[ 14.760640] mp_unmap_irq+0xb6/0x100[ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40[ 14.761334] acpi_pci_irq_disable+0x1d3/0x320[ 14.761688] pci_disable_device+0x1ad/0x380[ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60[ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821][ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821][ 14.763242] pci_device_remove+0x92/0x240Fix this by freeing the irq before call pci_disable_device().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix double free in si_parse_power_table()In function si_parse_power_table(), array adev->pm.dpm.ps and its memberis allocated. If the allocation of each member fails, the array itselfis freed and returned with an error code. However, the array is laterfreed again in si_dpm_fini() function which is called when the functionreturns an error.This leads to potential double free of the array adev->pm.dpm.ps, aswell as leak of its array members, since the members are not freed inthe allocation function and the array is not nulled when freed.In addition adev->pm.dpm.num_ps, which keeps track of the allocatedarray member, is not updated until the member allocation issuccessfully finished, this could also lead to either use after free,or uninitialized variable access in si_dpm_fini().Fix this by postponing the free of the array until si_dpm_fini() andincrement adev->pm.dpm.num_ps everytime the array member is allocated.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGIIf lpfc_issue_els_flogi() fails and returns non-zero status, the nodereference count is decremented to trigger the release of the nodeliststructure. However, if there is a prior registration or dev-loss-evt workpending, the node may be released prematurely. When dev-loss-evtcompletes, the released node is referenced causing a use-after-free nullpointer dereference.Similarly, when processing non-zero ELS PLOGI completion status inlpfc_cmpl_els_plogi(), the ndlp flags are checked for a transportregistration before triggering node removal. If dev-loss-evt work ispending, the node may be released prematurely and a subsequent call tolpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.Add test for pending dev-loss before decrementing the node reference countfor FLOGI, PLOGI, PRLI, and ADISC handling.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix call trace observed during I/O with CMF enabledThe following was seen with CMF enabled:BUG: using smp_processor_id() in preemptiblecode: systemd-udevd/31711kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc]kernel: CPU: 12 PID: 31711 Comm: systemd-udevdkernel: Call Trace:kernel: kernel: dump_stack_lvl+0x44/0x57kernel: check_preemption_disabled+0xbf/0xe0kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc]kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc]this_cpu_ptr() calls smp_processor_id() in a preemptible context.Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: jack: Access input_dev under mutexIt is possible when using ASoC that input_dev is unregistered whilecalling snd_jack_report, which causes NULL pointer dereference.In order to prevent this serialize access to input_dev using mutex lock.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hardlockup call trace hangs the system.Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40Kernel panic - not syncing: Hard LOCKUPThe same CPU tries to claim the phba->port_list_lock twice.Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() andlpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no needto take the phba->port_list_lock within lpfc_dmp_dbg().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipw2x00: Fix potential NULL dereference in libipw_xmit()crypt and crypt->ops could be null, so we need to checking nullbefore dereference
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: Fix buffer overflow in be_get_module_eeprombe_cmd_read_port_transceiver_data assumes that it is given a buffer thatis at least PAGE_DATA_LEN long, or twice that if the module supports SFF8472. However, this is not always the case.Fix this by passing the desired offset and length tobe_cmd_read_port_transceiver_data so that we only copy the bytes once.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_qrv.While reading sysctl_igmp_qrv, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igc: Reinstate IGC_REMOVED logic and implement it properlyThe initially merged version of the igc driver code (via commit146740f9abc4, "igc: Add support for PF") contained the followingIGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; }And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0)E.g. igb has similar checks in its MMIO accessors, and has a similarmacro E1000_REMOVED, which is implemented as follows: #define E1000_REMOVED(h) unlikely(!(h))These checks serve to detect and take note of an 0xffffffff MMIO readreturn from the device, which can be caused by a PCIe link flap or someother kind of PCI bus error, and to avoid performing MMIO reads andwrites from that point onwards.However, the IGC_REMOVED macro was not originally implemented: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */This led to the IGC_REMOVED logic to be removed entirely in asubsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVEDfunction"), with the rationale that such checks matter only forvirtualization and that igc does not support virtualization -- but aPCIe device can become detached even without virtualization being inuse, and without proper checks, a PCIe bus error affecting an igcadapter will lead to various NULL pointer dereferences, as the firstaccess after the error will set hw->hw_addr to NULL, and subsequentaccesses will blindly dereference this now-NULL pointer.This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), andimplements IGC_REMOVED the way it is done for igb, by checking for theunlikely() case of hw_addr being NULL. This change prevents the oopsesseen when a PCIe link flap occurs on an igc adapter.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()Yang Jihing reported a race between perf_event_set_output() andperf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list)After this; e1 is attached to an unmapped rb and a subsequentperf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } }The loop in perf_mmap_close() holds e2->mmap_mutex, while the attachin perf_event_set_output() holds e1->mmap_mutex. As such there is noserialization to avoid this race.Change perf_event_set_output() to take both e1->mmap_mutex ande2->mmap_mutex to alleviate that problem. Additionally, have the loopin perf_mmap() detach the rb directly, this avoids having to wait forthe concurrent perf_mmap_close() to get around to doing it to makeprogress.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix kernel panic when creating VFWhen creating VFs a kernel panic can happen when calling toefx_ef10_try_update_nic_stats_vf.When releasing a DMA coherent buffer, sometimes, I don't know in whatspecific circumstances, it has to unmap memory with vunmap. It isdisallowed to do that in IRQ context or with BH disabled. Otherwise, wehit this line in vunmap, causing the crash: BUG_ON(in_interrupt());This patch reenables BH to release the buffer.Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip...
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix use after free when disabling sriovUse after free is detected by kfence when disabling sriov. What was readafter being freed was vf->pci_dev: it was freed from pci_disable_sriovand later read in efx_ef10_sriov_free_vf_vports, called fromefx_ef10_sriov_free_vf_vswitching.Set the pointer to NULL at release time to not trying to read it later.Reproducer and dmesg log (note that kfence doesn't detect it every time):$ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs$ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/selftests: fix subtraction overflow bugOn some machines hole_end can be small enough to cause subtractionoverflow. On the other side (addr + 2 * min_alignment) can overflowin case of mock tests. This patch should handle both cases.(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: Fix data races in proc_douintvec_minmax().A sysctl variable is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.This patch changes proc_douintvec_minmax() to use READ_ONCE() andWRITE_ONCE() internally to fix data-races on the sysctl side. For now,proc_douintvec_minmax() itself is tolerant to a data-race, but we stillneed to add annotations on the other subsystem's side.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: Fix data races in proc_douintvec().A sysctl variable is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()internally to fix data-races on the sysctl side. For now, proc_douintvec()itself is tolerant to a data-race, but we still need to add annotations onthe other subsystem's side.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocateof_parse_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not needed anymore.Add missing of_node_put() in to fix this.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_open/close(): fix memory leakThe gs_usb driver appears to suffer from a malady common to many USBCAN adapter drivers in that it performs usb_alloc_coherent() toallocate a number of USB request blocks (URBs) for RX, and then laterrelies on usb_kill_anchored_urbs() to free them, but this doesn'tactually free them. As a result, this may be leaking DMA memory that'sbeen used by the driver.This commit is an adaptation of the techniques found in the esd_usb2driver where a similar design pattern led to a memory leak. Itexplicitly frees the RX URBs and their DMA memory via a call tousb_free_coherent(). Since the RX URBs were allocated in thegs_can_open(), we remove them in gs_can_close() rather than in thedisconnect function as was done in esd_usb2.For more information, see the 928150fad41b ("can: esd_usb2: fix memoryleak").
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix use-after-free after 802.3ad slave unbindcommit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),resolve case, when there is several aggregation groups in the same bond.bond_3ad_unbind_slave will invalidate (clear) aggregator when__agg_active_ports return zero. So, ad_clear_agg can be executed even, whennum_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slavewill not update slave ports list, because lag_ports==NULL. So, here wegot slave ports, pointing to freed aggregator memory.Fix with checking actual number of ports in group (as was beforecommit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),before ad_clear_agg().The KASAN logs are as follows:[ 767.617392] ==================================================================[ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470[ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767[ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15[ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)[ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler[ 767.666468] Call trace:[ 767.668930] dump_backtrace+0x0/0x2d0[ 767.672625] show_stack+0x24/0x30[ 767.675965] dump_stack_lvl+0x68/0x84[ 767.679659] print_address_description.constprop.0+0x74/0x2b8[ 767.685451] kasan_report+0x1f0/0x260[ 767.689148] __asan_load2+0x94/0xd0[ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: unlink NAPI from device on destructionSyzbot found a race between tun file and device destruction.NAPIs live in struct tun_file which can get destroyed beforethe netdev so we have to del them explicitly. The currentcode is missing deleting the NAPI if the queue was detachedfirst.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intfof_graph_get_remote_node() returns remote device node pointer withrefcount incremented, we should use of_node_put() on itwhen not need anymore.Add missing of_node_put() to avoid refcount leak.Patchwork: https://patchwork.freedesktop.org/patch/488473/
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed tofsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed infsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_iotriggers KASAN use-after-free. To avoid the use-after-free, keep thereference to mc->root_mc_bus_dev->mc_io in a local variable and pass tofsl_destroy_mc_io().This patch needs rework to apply to kernels older than v5.15.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitionsof_find_node_by_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix call trace in setup_tx_descriptorsAfter PF reset and ethtool -t there was call trace in dmesgsometimes leading to panic. When there was some time, around 5seconds, between reset and test there were no errors.Problem was that pf reset calls i40e_vsi_close in prep_for_resetand ethtool -t calls i40e_vsi_close in diag_test. If there was notenough time between those commands the second i40e_vsi_close startsbefore previous i40e_vsi_close was done which leads to crash.Add check to diag_test if pf is in reset and don't start offlinetests if it is true.Add netif_info("testing failed") into unhappy path of i40e_diag_test()
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()In an unlikely (and probably wrong?) case that the 'ppi' parameter ofata_host_alloc_pinfo() points to an array starting with a NULL pointer,there's going to be a kernel oops as the 'pi' local variable won't getreassigned from the initial value of NULL. Initialize 'pi' instead to'&ata_dummy_port_info' to fix the possible kernel oops for good...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix underflow in second superblock position calculationsMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the secondsuperblock, underflows when the argument device size is less than 4096bytes. Therefore, when using this macro, it is necessary to check inadvance that the device size is not less than a lower limit, or at leastthat underflow does not occur.The current nilfs2 implementation lacks this check, causing out-of-boundblock access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)In addition, when trying to resize the filesystem to a size below 4096bytes, this underflow occurs in nilfs_resize_fs(), passing a huge numberof segments to nilfs_sufile_resize(), corrupting parameters such as thenumber of segments in superblocks. This causes excessive loop iterationsin nilfs_sufile_resize() during a subsequent resize ioctl, causingsemaphore ns_segctor_sem to block for a long time and hang the writerthread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 ... Call Trace: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...This fixes these issues by inserting appropriate minimum device sizechecks or anti-underflow checks, depending on where the macro is used.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst->flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon't call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&wait->completion), which will causehungtask.The problem comes as following:(padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix refcnt handling in padata_free_shell()In a high-load arm64 environment, the pcrypt_aead01 test in LTP can leadto system UAF (Use-After-Free) issues. Due to the lengthy analysis ofthe pcrypt_aead01 function call, I'll describe the problem scenariousing a simplified model:Suppose there's a user of padata named `user_function` that adheres tothe padata requirement of calling `padata_free_shell` after `serial()`has been invoked, as demonstrated in the following code:```cstruct request { struct padata_priv padata; struct completion *done;};void parallel(struct padata_priv *padata) { do_something();}void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done);}void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell();}```In the corresponding padata.c file, there's the following code:```cstatic void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd);}```Because of the high system load and the accumulation of unexecutedsoftirq at this moment, `local_bh_enable()` in padata takes longerto execute than usual. Subsequently, when accessing `pd->refcnt`,`pd` has already been released by `padata_free_shell()`, resultingin a UAF issue with `pd->refcnt`.The fix is straightforward: add `refcount_dec_and_test` before calling`padata_free_pd` in `padata_free_shell`.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of boundsIf the "struct can_priv::echoo_skb" is accessed out of bounds, thiswould cause a kernel crash. Instead, issue a meaningful warningmessage and return with an error.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xferIn af9035_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9035_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: check cx23885_vdev_init() returncx23885_vdev_init() can return a NULL pointer, but that pointeris used in the next line without a check.Add a NULL pointer check and go to the error unwind if it is NULL.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: use the backlog for mirred ingressThe test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlogfor nested calls to mirred ingress") hangs our testing VMs every 10 or soruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported bylockdep.The problem as previously described by Davide (see Link) is thatif we reverse flow of traffic with the redirect (egress -> ingress)we may reach the same socket which generated the packet. And we maystill be holding its socket lock. The common solution to such deadlocksis to put the packet in the Rx backlog, rather than run the Rx pathinline. Do that for all egress -> ingress reversals, not just oncewe started to nest mirred calls.In the past there was a concern that the backlog indirection willlead to loss of error reporting / less accurate stats. But the currentworkaround does not seem to address the issue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Avoid potential use-after-free in hci_error_resetWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlyingBT controller is not responding, the GPIO reset mechanism wouldfree the hci_dev and lead to a use-after-free in hci_error_reset.Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30This patch holds the reference count on the hci_dev while processinga HCI_EV_HARDWARE_ERROR event to avoid potential crash.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets' ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: free rx_data_reassembly skb on NCI device cleanuprx_data_reassembly skb is stored during NCI data exchange for processingfragmented packets. It is dropped only when the last fragment is processedor when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.However, the NCI device may be deallocated before that which leads to skbleak.As by design the rx_data_reassembly skb is bound to the NCI device andnothing prevents the device to be freed before the skb is processed insome way and cleaned, free it on the NCI device cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Do not register event handler until srpt device is fully setupUpon rare occasions, KASAN reports a use-after-free Writein srpt_refresh_port().This seems to be because an event handler is registered before thesrpt device is fully setup and a race condition upon error may leave apartially setup event handler in place.Instead, only register the event handler after srpt device initializationis complete.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()Apply the same fix than ones found in :8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.syzbot reported:BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: af_bluetooth: Fix deadlockAttemting to do sock_lock on .recvmsg may cause a deadlock as shownbellow, so instead of using sock_sock this uses sk_receive_queue.lockon bt_sock_ioctl to avoid the UAF:INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183Workqueue: hci0 hci_rx_workCall Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-msm8974: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - resolve race condition during AER recoveryDuring the PCI AER system's error recovery process, the kernel drivermay encounter a race condition with freeing the reset_data structure'smemory. If the device restart will take more than 10 seconds the functionscheduling that restart will exit due to a timeout, and the reset_datastructure will be freed. However, this data structure is used forcompletion notification after the restart is completed, which leadsto a UAF bug.This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340To resolve this race condition, the memory associated to the containerof the work_struct is freed on the worker if the timeout expired,otherwise on the function that schedules the worker.The timeout detection can be done by checking if the caller isstill waiting for completion or not by using completion_done() function.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Always flush async #PF workqueue when vCPU is being destroyedAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing itscompletion queue, e.g. when a VM and all its vCPUs is being destroyed.KVM must ensure that none of its workqueue callbacks is running when thelast reference to the KVM _module_ is put. Gifting a reference to theassociated VM prevents the workqueue callback from dereferencing freedvCPU/VM memory, but does not prevent the KVM module from being unloadedbefore the callback completes.Drop the misguided VM refcount gifting, as calling kvm_put_kvm() fromasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue willresult in deadlock. async_pf_execute() can't return until kvm_put_kvm()finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,then there's no need to gift async_pf_execute() a reference because allinvocations of async_pf_execute() will be forced to complete before thevCPU and its VM are destroyed/freed. And that in turn fixes the moduleunloading bug as __fput() won't do module_put() on the last vCPU referenceuntil the vCPU has been freed, e.g. if closing the vCPU file also puts thelast reference to the KVM module.Note that kvm_check_async_pf_completion() may also take the work item offthe completion queue and so also needs to flush the work queue, as thework will not be seen by kvm_clear_async_pf_completion_queue(). Waitingon the workqueue could theoretically delay a vCPU due to waiting for thework to complete, but that's a very, very small chance, and likely a verysmall delay. kvm_arch_async_page_present_queued() unconditionally makes anew request, i.e. will effectively delay entering the guest, so theremaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm);and mmput() can't drop the last reference to the page tables if the vCPU isstill alive, i.e. the vCPU won't get stuck tearing down page tables.Add a helper to do the flushing, specifically to deal with "wakeup all"work items, as they aren't actually work items, i.e. are never placed in aworkqueue. Trying to flush a bogus workqueue entry rightly makes__flush_work() complain (kudos to whoever added that sanity check).Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check the inode number is not the invalid value of zeroSyskiller has produced an out of bounds access in fill_meta_index().That out of bounds access is ultimately caused because the inodehas an inode number with the invalid value of zero, which was not checked.The reason this causes the out of bounds access is due to followingsequence of events:1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode numberis not zero when the inode is created and returns -EINVAL if it is.[phillip@squashfs.org.uk: whitespace fix]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix mirred deadlock on device recursionWhen the mirred action is used on a classful egress qdisc and a packet ismirrored or redirected to self we hit a qdisc lock deadlock.See trace below.[..... other info removed for brevity....][ 82.890906][ 82.890906] ============================================[ 82.890906] WARNING: possible recursive locking detected[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W[ 82.890906] --------------------------------------------[ 82.890906] ping/418 is trying to acquire lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] but task is already holding lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] other info that might help us debug this:[ 82.890906] Possible unsafe locking scenario:[ 82.890906][ 82.890906] CPU0[ 82.890906] ----[ 82.890906] lock(&sch->q.lock);[ 82.890906] lock(&sch->q.lock);[ 82.890906][ 82.890906] *** DEADLOCK ***[ 82.890906][..... other info removed for brevity....]Example setup (eth0->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0Another example(eth0->eth1->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1tc qdisc add dev eth1 root handle 1: htb default 30tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0We fix this by adding an owner field (CPU id) to struct Qdisc set afterroot qdisc is entered. When the softirq enters it a second time, if theqdisc owner is the same CPU, the packet is dropped to break the loop.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute groupThe DisplayPort driver's sysfs nodes may be present to the userspace beforetypec_altmode_set_drvdata() completes in dp_altmode_probe. This means thata sysfs read can trigger a NULL pointer error by deferencing dp->hpd inhpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returnsNULL in those cases.Remove manual sysfs node creation in favor of adding attribute group asdefault for devices bound to the driver. The ATTRIBUTE_GROUPS() macro isnot used here otherwise the path to the sysfs nodes is no longer compliantwith the ABI.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid: really frozen sync_thread during suspend1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes().2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used.3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend().4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), thetest shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),and with previous fixes, the test won't hang there anymore, however, thetest will still fail and complain that ext4 is corrupted. And with thispatch, the test won't hang due to stop_sync_thread() or fail due to ext4is corrupted anymore. However, there is still a deadlock related todm-raid456 that will be fixed in following patches.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: Set page uptodate in the correct placePage cache reads are lockless, so setting the freshly allocated pageuptodate before we've overwritten it with the data it's supposed to havein it will allow a simultaneous reader to see old data. Move the callto SetPageUptodate into ubifs_write_end(), which is after we copied thenew data into the page.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Prevent double free on errorThe error handling path in its_vpe_irq_domain_alloc() causes a double freewhen its_vpe_init() fails after successfully allocating at least oneinterrupt. This happens because its_vpe_irq_domain_free() frees theinterrupts along with the area bitmap and the vprop_page andits_vpe_irq_domain_alloc() subsequently frees the area bitmap and thevprop_page again.Fix this by unconditionally invoking its_vpe_irq_domain_free() whichhandles all cases correctly and by removing the bitmap/vprop_page freeingfrom its_vpe_irq_domain_alloc().[ tglx: Massaged change log ]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe corresponding netns has been dismantled.Fortunately Josef Bacik could trigger the issue more often,and could test a patch I wrote two years ago.When TCP sockets are closed, we call inet_csk_clear_xmit_timers()to 'stop' the timers.inet_csk_clear_xmit_timers() can be called from any context,including when socket lock is held.This is the reason it uses sk_stop_timer(), aka del_timer().This means that ongoing timers might finish much later.For user sockets, this is fine because each running timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare terminated before the kernel socket is released.Modules using kernel sockets close them in their netns exit()handler.Also add sock_not_owned_by_me() helper to get LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e ("net: rds: acquire refcount on TCP sockets")which attempted to solve the issue in rds only.(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)We probably can remove the check_net() tests fromtcp_out_of_resources() and __tcp_close() in the future.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encryptedIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus ring buffer code could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the structvmbus_gpadl for the ring buffers to decide whether to free the memory.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Reapply "drm/qxl: simplify qxl_fence_wait"This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"and further debugging points to a possible circular locking dependencybetween the console_owner locking and the worker pool locking.Reverting the commit allows Steve's VM to boot to completion again.[ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in:---[ end trace 0000000000000000 ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix possible use-after-free issue in ftrace_location()KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79The root cause is that, in lookup_rec(), ftrace record of some addressis being searched in ftrace pages of some module, but those ftrace pagesat the same time is being freed in ftrace_release_mod() as thecorresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free!To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix possible dead-lock in nr_rt_ioctl()syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)[1]WARNING: possible circular locking dependency detected6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted------------------------------------------------------syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK ***1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn't update the respective globalvariable and after insmod - rmmod - insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Lock port->lock when calling uart_handle_cts_change()uart_handle_cts_change() has to be called with port lock taken,Since we run it in a separate work, the lock may not be taken atthe time of running. Make sure that it's taken by explicitly doingthat. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible race in __fib6_drop_pcpu_from()syzbot found a race in __fib6_drop_pcpu_from() [1]If compiler reads more than once (*ppcpu_rt),second read could read NULL, if another cpu clearsthe value in rt6_get_pcpu_route().Add a READ_ONCE() to prevent this race.Also add rcu_read_lock()/rcu_read_unlock() becausewe rely on RCU protection while dereferencing pcpu_rt.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48RSP: 0018:ffffc900040df070 EFLAGS: 00010206RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Lock wiphy in cfg80211_get_stationWiphy should be locked before calling rdev_get_station() (see lockdepassert in ieee80211_get_station()).This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)This happens because STA has time to disconnect and reconnect beforebatadv_v_elp_throughput_metric_update() delayed work gets scheduled. Inthis situation, ath10k_sta_state() can be in the middle of resettingarsta data when the work queue get chance to be scheduled and ends upaccessing it. Locking wiphy prevents that.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ecdh - explicitly zeroize private_keyprivate_key is overwritten with the key parameter passed in by thecaller (if present), or alternatively a newly generated private key.However, it is possible that the caller provides a key (or the newlygenerated key) which is shorter than the previous key. In thatscenario, some key material from the previous key would not beoverwritten. The easiest solution is to explicitly zeroize the entireprivate_key array first.Note that this patch slightly changes the behavior of this function:previously, if the ecc_gen_privkey failed, the old private_key wouldremain. Now, the private_key is always zeroized. This behavior isconsistent with the case where params.key is set and ecc_is_key_validfails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM valuessyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUMto 2^31.We had a similar issue in sch_fq, fixed with commitd9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]Modules linked in:irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Workqueue: mld mld_ifc_workpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854sp : ffff800093d36700x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffffx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fcx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn't have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: check dot and dotdot of dx_root before making dir indexedSyzbot reports a issue as follows:============================================BUG: unable to handle page fault for address: ffffed11022e24fePGD 23ffee067 P4D 23ffee067 PUD 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214[...]============================================The immediate cause of this problem is that there is only one valid dentryfor the block to be split during do_split, so split==0 results in out ofbounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295]The maximum length of a filename is 255 and the minimum block size is 1024,so it is always guaranteed that the number of entries is greater than orequal to 2 when do_split() is called.But syzbot's crafted image has no dot and dotdot in dir, and the dentrydistribution in dirblock is as follows: bus dentry1 hole dentry2 free|xx--|xx-------------|...............|xx-------------|...............|0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024So when renaming dentry1 increases its name_len length by 1, neither holenor free is sufficient to hold the new dentry, and make_indexed_dir() iscalled.In make_indexed_dir() it is assumed that the first two entries of thedirblock must be dot and dotdot, so bus and dentry1 are left in dx_rootbecause they are treated as dot and dotdot, and only dentry2 is movedto the new leaf block. That's why count is equal to 1.Therefore add the ext4_check_dx_root() helper function to add more sanitychecks to dot and dotdot before starting the conversion to avoid the aboveissue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid using corrupted block bitmap bufferWhen the filesystem block bitmap is corrupted, we detect the corruptionwhile loading the bitmap and fail the allocation with error. However thenext allocation from the same bitmap will notice the bitmap buffer isalready loaded and tries to allocate from the bitmap with mixed results(depending on the exact nature of the bitmap corruption). Fix theproblem by using BH_verified bit to indicate whether the bitmap is validor not.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ("net: Use nested-BH locking fornapi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it's running in NAPI contexteven when it's not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Add error handling to pair_device()hci_conn_params_add() never checks for a NULL value and could lead to a NULLpointer dereference causing a crash.Fixed by adding error handling in the function.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null pointer deref in dcn20_resource.cFixes a hang thats triggered when MPV is run on a DCN401 dGPU:mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=alland then enabling fullscreen playback (double click on the video)The following calltrace will be seen:[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 181.843997] #PF: supervisor instruction fetch in kernel mode[ 181.844003] #PF: error_code(0x0010) - not-present page[ 181.844009] PGD 0 P4D 0[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018[ 181.844044] RIP: 0010:0x0[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0[ 181.844141] Call Trace:[ 181.844146] [ 181.844153] ? show_regs+0x6d/0x80[ 181.844167] ? __die+0x24/0x80[ 181.844179] ? page_fault_oops+0x99/0x1b0[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0[ 181.844204] ? exc_page_fault+0x83/0x1b0[ 181.844216] ? asm_exc_page_fault+0x27/0x30[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu][ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu][ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu][ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu][ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu][ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference for smu7optimize the code to avoid pass a null pointer (hwmgr->backend)to function smu7_update_edc_leakage_table.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: avoid BUG_ON() while continue reshape after reassemblingCurrently, mdadm support --revert-reshape to abort the reshape whilereassembling, as the test 07revert-grow. However, following BUG_ON()can be triggerred by the test:kernel BUG at drivers/md/raid5.c:6278!invalid opcode: 0000 [#1] PREEMPT SMP PTIirq event stamp: 158985CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94RIP: 0010:reshape_request+0x3f1/0xe60Call Trace: raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 Root cause is that --revert-reshape update the raid_disks from 5 to 4,while reshape position is still set, and after reassembling the array,reshape position will be read from super block, then during reshape thechecking of 'writepos' that is caculated by old reshape position willfail.Fix this panic the easy way first, by converting the BUG_ON() toWARN_ON(), and stop the reshape if checkings fail.Noted that mdadm must fix --revert-shape as well, and probably md/raidshould enhance metadata validation as well, however this meansreassemble will fail and there must be user tools to fix the wrongmetadata.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: prevent potential speculation leaks in gpio_device_get_desc()Userspace may trigger a speculative read of an address outside the gpiodescriptor array.Users can do that by calling gpio_ioctl() with an offset out of range.Offset is copied from user and then used as an array index to getthe gpio descriptor without sanitization in gpio_device_get_desc().This change ensures that the offset is sanitized by usingarray_index_nospec() to mitigate any possibility of speculativeinformation leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: Initialize beyond-EOF page contents before setting uptodatefuse_notify_store(), unlike fuse_do_readpage(), does not enable pagezeroing (because it can be used to change partial page contents).So fuse_notify_store() must be more careful to fully initialize pagecontents (including parts of the page that are beyond end-of-file)before marking the page uptodate.The current code can leave beyond-EOF page contents uninitialized, whichmakes these uninitialized page contents visible to userspace via mmap().This is an information leak, but only affects systems which do notenable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or thecorresponding kernel command line parameter).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mtrr: Check if fixed MTRRs exist before saving themMTRRs have an obsolete fixed variant for fine grained caching controlof the 640K-1MB region that uses separate MSRs. This fixed variant hasa separate capability bit in the MTRR capability MSR.So far all x86 CPUs which support MTRR have this separate bit set, so itwent unnoticed that mtrr_save_state() does not check the capability bitbefore accessing the fixed MTRR MSRs.Though on a CPU that does not support the fixed MTRR capability thisresults in a #GP. The #GP itself is harmless because the RDMSR fault ishandled gracefully, but results in a WARN_ON().Add the missing capability check to prevent this.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: fix invalid FIFO access with special register setWhen enabling access to the special register set, Receiver time-out andRHR interrupts can happen. In this case, the IRQ handler will try to readfrom the FIFO thru the RHR register at address 0x00, but address 0x00 ismapped to DLL register, resulting in erroneous FIFO reading.Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register setFix the problem by claiming the efr_lock mutex when accessing the Specialregister set.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: Fix racy access to midibufThere can be concurrent accesses to line6 midibuf from both the URBcompletion callback and the rawmidi API access. This could be a causeof KMSAN warning triggered by syzkaller below (so put as reported-byhere).This patch protects the midibuf call of the former code path with aspinlock for avoiding the possible races.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/smt: Fix unbalance sched_smt_present dec/incI got the following warn report while doing stress test:jump label: negative count!WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),the cpu offline failed, but sched_smt_present is decremented beforecalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, sofix it by incrementing sched_smt_present in the error path.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsIf the dpu_format_populate_layout() fails, then FB is prepared, but notcleaned up. This ends up leaking the pin_count on the GEM object andcauses a splat during DRM file closure:msm_obj->pin_countWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc[...]Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194irq event stamp: 129818hardirqs last enabled at (129817): [] console_unlock+0x118/0x124hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8csoftirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8softirqs last disabled at (129785): [] __do_softirq+0x14/0x20Patchwork: https://patchwork.freedesktop.org/patch/600714/
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent UAF in ip6_send_skb()syzbot reported an UAF in ip6_send_skb() [1]After ip6_local_out() has returned, we no longer can safelydereference rt, unless we hold rcu_read_lock().A similar issue has been fixed in commita688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")Another potential issue in ip6_finish_output2() is handled in aseparate patch.[1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f936bf79e79Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix a deadlock problem when config TC during resettingWhen config TC during the reset process, may cause a deadlock, the flow isas below: pf reset start | v ......setup tc | | v v DOWN: napi_disable()napi_disable()(skip) | | | v v ...... ...... | | v |napi_enable() | v UINIT: netif_napi_del() | v ...... | v INIT: netif_napi_add() | v ...... global reset start | | v v UP: napi_enable()(skip) ...... | | v v ...... napi_disable()In reset process, the driver will DOWN the port and then UINIT, in thiscase, the setup tc process will UP the port before UINIT, so cause theproblem. Adds a DOWN process in UINIT to fix it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: idt77252: prevent use after free in dequeue_rx()We can't dereference "skb" after calling vcc->push() because the skbis released.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: pull network headers in gtp_dev_xmit()syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]We must make sure the IPv4 or Ipv6 header is pulled in skb->headbefore accessing fields in them.Use pskb_inet_may_pull() to fix this issue.[1]BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memcg_write_event_control(): fix a user-triggerable oopswe are *not* guaranteed that anything past the terminating NULis mapped (let alone initialized with anything sane).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix a potential NULL pointer dereferenceWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns aNULL pointer, but its callers only check for error pointers thus missthe NULL pointer case.Fix it by returning an error pointer with the error code carried fromsockfd_lookup().(I found this bug during code inspection.)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereference in pcs_get_function()pinmux_generic_get_function() can return NULL and the pointer 'function'was dereferenced without checking against NULL. Add checking of pointer'function' in pcs_get_function().Found by code review.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()This happens when called from SMB2_read() while using rdmaand reaching the rdma_readwrite_threshold.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don't bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don't do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3On a system with a GICv3, if a guest hasn't been configured withGICv3 and that the host is not capable of GICv2 emulation,a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.We therefore try to emulate the SGI access, only to hit a NULLpointer as no private interrupt is allocated (no GIC, remember?).The obvious fix is to give the guest what it deserves, in theshape of a UNDEF exception.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event->mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver: iio: add missing checks on iio_info's callback accessSome callbacks from iio_info structure are accessed without any check, soif a driver doesn't implement them trying to access the correspondingsysfs entries produce a kernel oops such as:[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute[...][ 2203.783416] Call trace:[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0[ 2203.830363] Code: bad PC value[ 2203.832695] ---[ end trace 0000000000000000 ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix possible NULL pointer dereferenceprofile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is madefrom __create_missing_ancestors(..) and 'ent->old' is NULL inaa_replace_profiles(..).In that case, it must return an error code and the code, -ENOENT representsits state that the path of its parent is not existed yet.BUG: kernel NULL pointer dereference, address: 0000000000000030PGD 0 P4D 0PREEMPT SMP PTICPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80RIP: 0033:0x7be9f211c574Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesasCR2: 0000000000000030---[ end trace 0000000000000000 ]---RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix mc_data out-of-bounds read warningClear warning that read mc_data[i-1] may out-of-bounds.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix ucode out-of-bounds read warningClear warning that read ucode[] may out-of-bounds.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: sanity check symbolic link sizeSyzkiller reports a "KMSAN: uninit-value in pick_link" bug.This is caused by an uninitialised page, which is ultimately causedby a corrupted symbolic link size read from disk.The reason why the corrupted symlink size causes an uninitialisedpage is due to the following sequence of events:1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.This patch adds a sanity check which checks that the symboliclink size is not larger than expected.--V2: fix spelling mistake.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - reject requests with unreasonable number of slotsWhen exercising uinput interface syzkaller may try setting up devicewith a really large number of slots, which causes memory allocationfailure in input_mt_init_slots(). While this allocation failure ishandled properly and request is rejected, it results in syzkallerreports. Additionally, such request may put undue burden on thesystem which will try to free a lot of memory for a bogus request.Fix it by limiting allowed number of slots to 100. This can easilybe extended if we see devices that can track more than 100 contacts.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,aborting the transaction and logging an error message.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BUG_ON() with error handling at update_ref_for_cow()Instead of a BUG_ON() just return an error, log an error message andabort the transaction in case we find an extent buffer belonging to therelocation tree that doesn't have the full backref flag set. This isunexpected and should never happen (save for bugs or a potential badmemory).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle errors from btrfs_dec_ref() properlyIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This isincorrect, we have proper error handling here, return the error.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()mwifiex_get_priv_by_id() returns the priv pointer corresponding tothe bss_num and bss_type, but without checking if the priv is actuallycurrently in use.Unused priv pointers do not have a wiphy attached to them which canlead to NULL pointer dereferences further down the callstack. Fixthis by returning only used priv pointers which have priv->bss_modeset to something else than NL80211_IFTYPE_UNSPECIFIED.Said NULL pointer dereference happened when an Accesspoint was startedwith wpa_supplicant -i mlan0 with this config:network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678"}When waiting for the AP to be established, interrupting wpa_supplicantwith and starting it again this happens:| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140| Mem abort info:| ESR = 0x0000000096000004| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x04: level 0 translation fault| Data abort info:| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000| CM = 0, WnR = 0, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18| Hardware name: somemachine (DT)| Workqueue: events sdio_irq_work| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]| sp : ffff8000818b3a70| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000| Call trace:| mwifiex_get_cfp+0xd8/0x15c [mwifiex]| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]| mwifiex_process_event+0x110/0x238 [mwifiex]| mwifiex_main_process+0x428/0xa44 [mwifiex]| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]| process_sdio_pending_irqs+0x64/0x1b8| sdio_irq_work+0x4c/0x7c| process_one_work+0x148/0x2a0| worker_thread+0x2fc/0x40c| kthread+0x110/0x114| ret_from_fork+0x10/0x20| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)| ---[ end trace 0000000000000000 ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pci/hotplug/pnv_php: Fix hotplug driver crash on PowernvThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernelcrash when we try to hot-unplug/disable the PCIe switch/bridge fromthe PHB.The crash occurs because although the MSI data structure has beenreleased during disable/hot-unplug path and it has been assignedwith NULL, still during unregistration the code was again trying toexplicitly disable the MSI which causes the NULL pointer dereference andkernel crash.The patch fixes the check during unregistration path to prevent invokingpci_disable_msi/msix() since its data structure is already freed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add netif_device_attach/detach into PF reset flowEthtool callbacks can be executed while reset is in progress and try toaccess deleted resources, e.g. getting coalesce settings can result in aNULL pointer dereference seen below.Reproduction steps:Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net//device/resetwhen reset is in progress try to get coalesce settings using ethtool: # ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0Call Trace:ice_get_coalesce+0x17/0x30 [ice]coalesce_prepare_data+0x61/0x80ethnl_default_doit+0xde/0x340genl_family_rcv_msg_doit+0xf2/0x150genl_rcv_msg+0x1b3/0x2c0netlink_rcv_skb+0x5b/0x110genl_rcv+0x28/0x40netlink_unicast+0x19c/0x290netlink_sendmsg+0x222/0x490__sys_sendto+0x1df/0x1f0__x64_sys_sendto+0x24/0x30do_syscall_64+0x82/0x160entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7faee60d8e27Calling netif_device_detach() before reset makes the net core not callthe driver when ethtool command is issued, the attempt to execute anethtool command during reset will result in the following message: netlink error: No such deviceinstead of NULL pointer dereference. Once reset is done andice_rebuild() is executing, the netif_device_attach() is called to allowfor ethtool operations to occur again in a safe manner.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Remove proc entry when dev is unregistered.syzkaller reported a warning in bcm_connect() below. [0]The repro calls connect() to vxcan1, removes vxcan1, and callsconnect() with ifindex == 0.Calling connect() for a BCM socket allocates a proc entry.Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().However, removing the bound device resets bcm_sk(sk)->bound to 0in bcm_notify().The 2nd connect() tries to allocate a proc entry with the samename and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking theoriginal proc entry.Since the proc entry is available only for connect()ed sockets,let's clean up the entry when the bound netdev is unregistered.[0]:proc_dir_entry 'can-bcm/2456' already registeredWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375Modules linked in:CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ecFS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fbd708b0e5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5dRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid excessive partition lengthsAvoid mounting filesystems where the partition would overflow the32-bits used for block number. Also refuse to mount filesystems wherethe partition length is so large we cannot safely index bits in ablock bitmap.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: fix return value of tcp_bpf_sendmsg()When we cork messages in psock->cork, the last message triggers theflushing will result in sending a sk_msg larger than the currentmessage size. In this case, in tcp_bpf_send_verdict(), 'copied' becomesnegative at least in the following case:468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta); // <==== HERE473 return -EACCES;Therefore, it could lead to the following BUG with a proper value of'copied' (thanks to syzbot). We should not use negative 'copied' as areturn value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix checks for huge PMDsPatch series "userfaultfd: fix races around pmd_trans_huge() check", v2.The pmd_trans_huge() code in mfill_atomic() is wrong in three differentways depending on kernel version:1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr().3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong.I decided to write two separate fixes for these (one fix for bugs 1+2, onefix for bug 3), so that the first fix can be backported to kernelsaffected by bugs 1+2.This patch (of 2):This fixes two issues.I discovered that the following race can occur: mfill_atomic other thread ============ ============
pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd))I have experimentally verified this in a kernel with extra mdelay() calls;the BUG_ON(pmd_none(*dst_pmd)) triggers.On kernels newer than commit 0d940a9b270b ("mm/pgtable: allowpte_offset_map[_lock]() to fail"), this can't lead to anything worse thana BUG_ON(), since the page table access helpers are actually designed todeal with page tables concurrently disappearing; but on older kernels(<=6.4), I think we could probably theoretically race past the twoBUG_ON() checks and end up treating a hugepage as a page table.The second issue is that, as Qi Zheng pointed out, there are other typesof huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs(in particular, migration PMDs).On <=6.4, this is worse than the first issue: If mfill_atomic() runs on aPMD that contains a migration entry (which just requires winning a single,fairly wide race), it will pass the PMD to pte_offset_map_lock(), whichassumes that the PMD points to a page table.Breakage follows: First, the kernel tries to take the PTE lock (which willcrash or maybe worse if there is no "struct page" for the address bits inthe migration entry PMD - I think at least on X86 there usually is nocorresponding "struct page" thanks to the PTE inversion mitigation, amd64looks different).If that didn't crash, the kernel would next try to write a PTE into whatit wrongly thinks is a page table.As part of fixing these issues, get rid of the check for pmd_trans_huge()before __pte_alloc() - that's redundant, we're going to have to check forthat after the __pte_alloc() anyway.Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch/netem: fix use after free in netem_dequeueIf netem_dequeue() enqueues packet to inner qdisc and that qdiscreturns __NET_XMIT_STOLEN. The packet is dropped butqdisc_tree_reduce_backlog() is not called to update the parent'sq.qlen, leading to the similar use-after-free as Commite04991a48dbaf382 ("netem: fix return value if duplicate enqueuefails")Commands to trigger KASAN UaF:ip link add type dummyip link set lo upip link set dummy0 uptc qdisc add dev lo parent root handle 1: drrtc filter add dev lo parent 1: basic classid 1:1tc class add dev lo classid 1:1 drrtc qdisc add dev lo parent 1:1 handle 2: netemtc qdisc add dev lo parent 2: handle 3: drrtc filter add dev lo parent 3: basic classid 3:1 action mirred egressredirect dev dummy0tc class add dev lo classid 3:1 drrping -c1 -W0.01 localhost # Trigger bugtc class del dev lo classid 1:1tc class add dev lo classid 1:1 drrping -c1 -W0.01 localhost # UaF
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: added NULL check at start of dc_validate_stream[Why]prevent invalid memory access[How]check if dc and stream are NULL
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entryIn a review discussion of the changes to support vCPU hotplug wherea check was added on the GICC being enabled if was online, it wasnoted that there is need to map back to the cpu and use that to indexinto a cpumask. As such, a valid ID is needed.If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possiblefor the entry in cpu_madt_gicc[cpu] == NULL. This function wouldthen cause a NULL pointer dereference. Whilst a path to triggerthis has not been established, harden this caller against thepossibility.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ELF: fix kernel.randomize_va_space double readELF loader uses "randomize_va_space" twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: clean up our handling of refs == 0 in snapshot deleteIn reada we BUG_ON(refs == 0), which could be unkind since we aren'tholding a lock on the extent leaf and thus could get a transientincorrect answer. In walk_down_proc we also BUG_ON(refs == 0), whichcould happen if we have extent tree corruption. Change that to return-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,however we return -EIO, which -EUCLEAN is a more appropriate error code.Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convertthat to proper error handling. Also adjust the error message so we canactually do something with the information.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()We handle errors here properly, ENOMEM isn't fatal, return the error.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Limit the period on HaswellRunning the ltp test cve-2015-3290 concurrently reports the followingwarnings.perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330Thanks to Thomas Gleixner's analysis, the issue is caused by the lowinitial period (1) of the frequency estimation algorithm, which triggersthe defects of the HW, specifically erratum HSW11 and HSW143. (For thedetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)The HSW11 requires a period larger than 100 for the INST_RETIRED.ALLevent, but the initial period in the freq mode is 1. The erratum is thesame as the BDM11, which has been supported in the kernel. A minimumperiod of 128 is enforced as well on HSW.HSW143 is regarding that the fixed counter 1 may overcount 32 with theHyper-Threading is enabled. However, based on the test, the hardwarehas more issues than it tells. Besides the fixed counter 1, the message'interrupt took too long' can be observed on any counter which was armedwith a period < 32 and two events expired in the same NMI. A minimumperiod of 32 is enforced for the rest of the events.The recommended workaround code of the HSW143 is not implemented.Because it only addresses the issue for the fixed counter. It bringsextra overhead through extra MSR writing. No related overcounting issuehas been reported so far.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: panasonic-laptop: Fix SINF array out of bounds accessesThe panasonic laptop code in various places uses the SINF array with indexvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF arrayis big enough.Not all panasonic laptops have this many SINF array entries, for examplethe Toughbook CF-18 model only has 10 SINF array entries. So it onlysupports the AC+DC brightness entries and mute.Check that the SINF array has a minimum size which covers all AC+DCbrightness entries and refuse to load if the SINF array is smaller.For higher SINF indexes hide the sysfs attributes when the SINF arraydoes not contain an entry for that attribute, avoiding show()/store()accessing the array out of bounds and add bounds checking to the probe()and resume() code accessing these.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy->enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late. After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: change the order of rate limitsICMP messages are ratelimited :After the blamed commits, the two rate limiters are applied in this order:1) host wide ratelimit (icmp_global_allow())2) Per destination ratelimit (inetpeer based)In order to avoid side-channels attacks, we need to applythe per destination check first.This patch makes the following change :1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3)2) The per destination limit is checked/updated. This might add a new node in inetpeer tree.3) icmp_global_consume() consumes tokens if prior operations succeeded.This means that host wide ratelimit is still effectivein keeping inetpeer tree small even under DDOS.As a bonus, I removed icmp_global.lock as the fast pathcan use a lock-free operation.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,as spotted by syzbot:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8cR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f1acc77def9Code: Unable to access opcode bytes at 0x7f1acc77decf.RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in:---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0R---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()Since '__dev_queue_xmit()' should be called with interrupts enabled,the following backtrace:ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)issues the warning (as reported by syzbot reproducer):WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120Fix this by implementing a two-phase skb reclamation in'ieee80211_do_stop()', where actual work is performedoutside of a section with interrupts disabled.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabledFix missuse of spin_lock_irq()/spin_unlock_irq() whenspin_lock_irqsave()/spin_lock_irqrestore() was hold.This was discovered through the lock debugging, and the correspondinglog is as follows:raw_local_irq_restore() called with IRQs enabledWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40...Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
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:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Clean up TPM space after command failuretpm_dev_transmit prepares the TPM space before attempting commandtransmission. However if the command fails no rollback of thispreparation is done. This can result in transient handles being leakedif the device is subsequently closed with no further commands performed.Fix this by flushing the space in the event of command transmissionfailure.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: update orig_path in ext4_find_extent()In ext4_find_extent(), if the path is not big enough, we free it and set*orig_path to NULL. But after reallocating and successfully initializingthe path, we don't update *orig_path, in which case the caller gets avalid path but a NULL ppath, and this may cause a NULL pointer dereferenceor a path memory leak. For example:ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference!==================================================================BUG: kernel NULL pointer dereference, address: 0000000000000010CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847RIP: 0010:ext4_split_extent_at+0x6d/0x560Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0[...]==================================================================Therefore, *orig_path is updated when the extent lookup succeeds, so thatthe caller can safely use path or *ppath.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double brelse() the buffer of the extents pathIn ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has beenreleased, otherwise it may be released twice. An example of what triggersthis is as follows: split2 map split1|--------|-------|--------|ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twiceFinally got the following WARRNING when removing the buffer from lru:============================================VFS: brelse: Trying to free free bufferWARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716RIP: 0010:__brelse+0x58/0x90Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]============================================
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: aovid use-after-free in ext4_ext_insert_extent()As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path isreallocated in ext4_ext_create_new_leaf(), we'll use the stale path andcause UAF. Below is a sample trace with dummy values:ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr==================================================================BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800[...]Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]==================================================================So use *ppath to update the path to avoid the above problem.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix slab-use-after-free in ext4_split_extent_at()We hit the following use-after-free:==================================================================BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]==================================================================The flow of issue triggering is as follows:ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!!So when trying to zeroout or fix the extent length, call ext4_find_extent()to update the path.In addition we use *ppath directly as an ext4_ext_show_leaf() input toavoid possible use-after-free when EXT_DEBUG is defined, and to avoidunnecessary path updates.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: ensure the fw_info is not null before using itThis resolves the dereference null return value warningreported by Coverity.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata pathsWhen the HBA is undergoing a reset or is handling an errata event, NULL ptrdereference crashes may occur in routines such aslpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), orlpfc_abort_handler().Add NULL ptr checks before dereferencing hdwq pointers that may have beenfreed due to operations colliding with a reset or errata event handler.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check stream before comparing them[WHAT & HOW]amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It isnecessary to check for null before dereferencing them.This fixes 1 FORWARD_NULL issue reported by Coverity.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0
48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash> dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 : mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14]$66 = 0xffffffffcrash> px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash> sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash> px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmitSyzbot points out that skb_trim() has a sanity check on the existing length ofthe skb, which can be uninitialised in some error paths. The intent here isclearly just to reset the length to zero before resubmitting, so switch tocalling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()already contains a call to skb_reset_tail_pointer(), so remove the redundantcall.The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similarusage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_startIn sctp_listen_start() invoked by sctp_inet_listen(), it should set thesk_state back to CLOSED if sctp_autobind() fails due to whatever reason.Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuseis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash willbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hashis NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ncsi: Disable the ncsi work before freeing the associated structureThe work function can run after the ncsi device is freed, resultingin use-after-free bugs or kernel panic.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious 'GSO' packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ("net: be more gentle about silly gsorequests coming from user") virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: counttransport header in UFO") while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb->lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size);Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix uaf in l2cap_connect[Syzbot reported]BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Workqueue: hci2 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 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 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 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...Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 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:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prevent nf_skb_duplicated corruptionsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could writeper-cpu variable nf_skb_duplicated in an unsafe way [1].Disabling preemption as hinted by the splat is not enough,we have to disable soft interrupts as well.[1]BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f4ce4f7def9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: reserve space for inline xattr before attaching reflink treeOne of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting,the fsck -fn output showed the below corruption[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,but fsck believes the largest valid value is 227. Clamp the next record value? nThe stat output from the debugfs.ocfs2 showed the following corruptionwhere the "Next Free Rec:" had overshot the "Count:" in the root metadatablock. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... .......The issue was in the reflink workfow while reserving space for inlinexattr. The problematic function is ocfs2_reflink_xattr_inline(). By thetime this function is called the reflink tree is already recreated at thedestination inode from the source inode. At this point, this functionreserves space for inline xattrs at the destination inode without evenchecking if there is space at the root metadata block. It simply reducesthe l_count from 243 to 227 thereby making space of 256 bytes for inlinexattr whereas the inode already has extents beyond this index (in thiscase up to 230), thereby causing corruption.The fix for this is to reserve space for inline metadata at the destinationinode before the reflink tree gets recreated. The customer has verified thefix.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns errorIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()to recover some journal space. But if an error occurs while executingjbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for freespace right away, we try other branches, and if j_committing_transactionis NULL (i.e., the tid is 0), we will get the following complain:============================================JBD2: I/O error when updating journal superblock for sdd-8.__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available__jbd2_log_wait_for_space: no way to get more journal space in sdd-8------------[ cut here ]------------WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0Modules linked in:CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70[...]============================================So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing toclean up at the moment, continue to try to reclaim free space in other ways.Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corruptwhen updating journal superblock fails") to make jbd2_cleanup_journal_tailreturn the correct error code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: bcm2835: Fix timeout during suspend modeDuring noirq suspend phase the Raspberry Pi power driver suffer offirmware property timeouts. The reason is that the IRQ of the underlyingBCM2835 mailbox is disabled and rpi_firmware_property_list() will alwaysrun into a timeout [1].Since the VideoCore side isn't consider as a wakeup source, set theIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabledduring suspend-resume cycle.[1]PM: late suspend of devices complete after 1.754 msecsWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22cFirmware transaction 0x00028001 timeoutModules linked in:CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17Hardware name: BCM2835Call trace:unwind_backtrace from show_stack+0x18/0x1cshow_stack from dump_stack_lvl+0x34/0x44dump_stack_lvl from __warn+0x88/0xec__warn from warn_slowpath_fmt+0x7c/0xb0warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22crpi_firmware_property_list from rpi_firmware_property+0x68/0x8crpi_firmware_property from rpi_firmware_set_power+0x54/0xc0rpi_firmware_set_power from _genpd_power_off+0xe4/0x148_genpd_power_off from genpd_sync_power_off+0x7c/0x11cgenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0genpd_finish_suspend from dpm_run_callback+0x78/0xd0dpm_run_callback from device_suspend_noirq+0xc0/0x238device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5acsuspend_devices_and_enter from pm_suspend+0x254/0x2e4pm_suspend from state_store+0xa8/0xd4state_store from kernfs_fop_write_iter+0x154/0x1a0kernfs_fop_write_iter from vfs_write+0x12c/0x184vfs_write from ksys_write+0x78/0xc0ksys_write from ret_fast_syscall+0x0/0x54Exception stack(0xcc93dfa8 to 0xcc93dff0)[...]PM: noirq suspend of devices complete after 3095.584 msecs
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: cancel dqi_sync_work before freeing oinfoocfs2_global_read_info() will initialize and schedule dqi_sync_work at theend, if error occurs after successfully reading global quota, it willtrigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16cThis reports that there is an active delayed work when freeing oinfo inerror handling, so cancel dqi_sync_work first. BTW, return status insteadof -1 when .read_file_info fails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: fix kernel info leak via "[uprobes]" vmaxol_add_vma() maps the uninitialized page allocated by __create_xol_area()into userspace. On some architectures (x86) this memory is readable evenwithout VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,although this doesn't really matter, debugger can read this memory anyway.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix buffer overflow when parsing NFS reparse pointsReparseDataLength is sum of the InodeType size and DataBuffer size.So to get DataBuffer size it is needed to subtract InodeType's size fromReparseDataLength.Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBufferat position after the end of the buffer because it does not subtractInodeType size from the length. Fix this problem and correctly subtractvariable len.Member InodeType is present only when reparse buffer is large enough. Checkfor ReparseDataLength before accessing InodeType to prevent another invalidmemory access.Major and minor rdev values are present also only when reparse buffer islarge enough. Check for reparse buffer size before calling reparse_mkdev().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix an unsafe loop on the listThe kernel may crash when deleting a genetlink family if there are stilllisteners for that family:Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace:__netlink_clear_multicast_users+0x74/0xc0genl_unregister_family+0xd4/0x2d0Change the unsafe loop on the list to a safe one, because inside theloop there is an element removal from this list.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slip: make slhc_remember() more robust against malicious packetssyzbot found that slhc_remember() was missing checks againstmalicious packets [1].slhc_remember() only checked the size of the packet was at least 20,which is not good enough.We need to make sure the packet includes the IPv4 and TCP headerthat are supposed to be carried.Add iph and th pointers to make the code more readable.[1]BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: do not delay dst_entries_add() in dst_release()dst_entries_add() uses per-cpu data that might be freed at netnsdismantle from ip6_route_net_exit() calling dst_entries_destroy()Before ip6_route_net_exit() can be called, we release allthe dsts associated with this netns, via calls to dst_release(),which waits an rcu grace period before calling dst_destroy()dst_entries_add() use in dst_destroy() is racy, becausedst_entries_destroy() could have been called already.Decrementing the number of dsts must happen sooner.Notes:1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this.2) There is also discussion about removing this count of dst, which might happen in future kernels.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_changerfcomm_sk_state_change attempts to use sock_lock so it must never becalled with it locked but rfcomm_sock_ioctl always attempt to lock itcausing the following trace:======================================================WARNING: possible circular locking dependency detected6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted------------------------------------------------------syz-executor386/5093 is trying to acquire lock:ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73but task is already holding lock:ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: br_netfilter: fix panic with metadata_dst skbFix a kernel panic in the br_netfilter module when sending untaggedtraffic via a VxLAN device.This happens during the check for fragmentation in br_nf_dev_queue_xmit.It is dependent on:1) the br_netfilter module being loaded;2) net.bridge.bridge-nf-call-iptables set to 1;3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;4) untagged frames with size higher than the VxLAN MTU forwarded/floodedWhen forwarding the untagged packet to the VxLAN bridge port, beforethe netfilter hooks are called, br_handle_egress_vlan_tunnel is called andchanges the skb_dst to the tunnel dst. The tunnel_dst is a metadata typeof dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a checkfor frames that needs to be fragmented: frames with higher MTU than theVxLAN device end up calling br_nf_ip_fragment, which in turns callip_skb_dst_mtu.The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dstwith valid dst->dev, thus the crash.This case was never supported in the first place, so drop the packetinstead.PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.[ 176.291791] Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000110[ 176.292101] Mem abort info:[ 176.292184] ESR = 0x0000000096000004[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits[ 176.292530] SET = 0, FnV = 0[ 176.292709] EA = 0, S1PTW = 0[ 176.292862] FSC = 0x04: level 0 translation fault[ 176.293013] Data abort info:[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000[ 176.294166] [0000000000000110] pgd=0000000000000000,p4d=0000000000000000[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel vethbr_netfilter bridge stp llc ipv6 crct10dif_ce[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted6.8.0-rc3-g5b3fbd61b9d1 #2[ 176.296314] Hardware name: linux,dummy-virt (DT)[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBSBTYPE=--)[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter][ 176.297636] sp : ffff800080003630[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:ffff6828c49ad9f8[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:00000000000003e8[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:ffff6828c3b16d28[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:0000000000000014[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:0000000095744632[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:ffffb7e137926a70[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :0000000000000000[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :f20e0100bebafeca[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :0000000000000000[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :ffff6828c7f918f0[ 176.300889] Call trace:[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter][ 176.301703] nf_hook_slow+0x48/0x124[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge][ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter][ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter][ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter][ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter][ 176.303359] nf_hook_slow+0x48/0x124[ 176.303---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: bus: Fix double free in driver API bus_register()For bus_register(), any error which happens after kset_register() willcause that @priv are freed twice, fixed by setting @priv with NULL afterthe first free.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: protect uart_port_dtr_rts() in uart_shutdown() tooCommit af224ca2df29 (serial: core: Prevent unsafe uart port access, part3) added few uport == NULL checks. It added one to uart_shutdown(), sothe commit assumes, uport can be NULL in there. But right after thatprotection, there is an unprotected "uart_port_dtr_rts(uport, false);"call. That is invoked only if HUPCL is set, so I assume that is thereason why we do not see lots of these reports.Or it cannot be NULL at this point at all for some reason :P.Until the above is investigated, stay on the safe side and move thisdereference to the if too.I got this inconsistency from Coverity under CID 1585130. Thanks.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
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:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parport: Proper fix for array out-of-bounds accessThe recent fix for array out-of-bounds accesses replaced sprintf()calls blindly with snprintf(). However, since snprintf() returns thewould-be-printed size, not the actually output size, the lengthcalculation can still go over the given limit.Use scnprintf() instead of snprintf(), which returns the actuallyoutput letters, for addressing the potential out-of-bounds accessproperly.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mad: Improve handling of timed out WRs of mad agentCurrent timeout handler of mad agent acquires/releases mad_agent_privlock for every timed out WRs. This causes heavy locking contentionwhen higher no. of WRs are to be handled inside timeout handler.This leads to softlockup with below trace in some use cases whererdma-cm path is used to establish connection between peer nodesTrace:----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRsand invoke send handler post creating the list. The new method acquires/releases lock once to fetch the list and hence helps to reduce lockingcontetiong when processing higher no. of WRs
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: fix potential memory leak in be_xmit()The be_xmit() returns NETDEV_TX_OK without freeing skbin case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Stop the active perfmon before being destroyedUpon closing the file descriptor, the active performance monitor is notstopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,the active performance monitor's pointer (`vc4->active_perfmon`) is stillretained.If we open a new file descriptor and submit a few jobs with performancemonitors, the driver will attempt to stop the active performance monitorusing the stale pointer in `vc4->active_perfmon`. However, this pointeris no longer valid because the previous process has already terminated,and all performance monitors associated with it have been destroyed andfreed.To fix this, when the active performance monitor belongs to a givenprocess, explicitly stop it before destroying and freeing it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-clock: Fix missing timespec64 check in pc_clock_settime()As Andrew pointed out, it will make sense that the PTP corechecked timespec64 struct's tv_sec and tv_nsec range before callingptp->info->settime64().As the man manual of clock_settime() said, if tp.tv_sec is negative ortp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,which include dynamic clocks which handles PTP clock, and the condition isconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()only check the timespec is valid, but not ensure that the time isin a valid range, so check it ahead using timespec64_valid_strict()in pc_clock_settime() and return -EINVAL if not valid.There are some drivers that use tp->tv_sec and tp->tv_nsec directly towrite registers without validity checks and assume that the higher layerhas checked it, which is dangerous and will benefit from this, such ashclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),and some drivers can remove the checks of itself.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: pass u64 to ocfs2_truncate_inline maybe overflowSyzbot reported a kernel BUG in ocfs2_truncate_inline. There are tworeasons for this: first, the parameter value passed is greater thanocfs2_max_inline_data_with_xattr, second, the start and end parameters ofocfs2_truncate_inline are "unsigned int".So, we need to add a sanity check for byte_start and byte_len right beforeocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greaterthan ocfs2_max_inline_data_with_xattr return -EINVAL.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: do not pass a stopped vif to the driver in .get_txpowerAvoid potentially crashing in the driver because of uninitialized private data
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reinitialize delayed ref list after deleting it from the listAt insert_delayed_ref() if we need to update the action of an existingref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head'sref_add_list using list_del(), which leaves the ref's add_list membernot reinitialized, as list_del() sets the next and prev members of thelist to LIST_POISON1 and LIST_POISON2, respectively.If later we end up calling drop_delayed_ref() against the ref, which canhappen during merging or when destroying delayed refs due to a transactionabort, we can trigger a crash since at drop_delayed_ref() we calllist_empty() against the ref's add_list, which returns false sincethe list was not reinitialized after the list_del() and as a consequencewe call list_del() again at drop_delayed_ref(). This results in aninvalid list access since the next and prev members are set to poisonpointers, resulting in a splat if CONFIG_LIST_HARDENED andCONFIG_DEBUG_LIST are set or invalid poison pointer dereferencesotherwise.So fix this by deleting from the list with list_del_init() instead.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: prevent the risk of a division by zeroAs reported by Coverity, the logic at tpg_precalculate_line()blindly rescales the buffer even when scaled_witdh is equal tozero. If this ever happens, this will cause a division by zero.Instead, add a WARN_ON_ONCE() to trigger such cases and returnwithout doing any precalculation.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: av7110: fix a spectre vulnerabilityAs warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)There is a spectre-related vulnerability at the code. Fix it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when uninstalling driverWhen the driver is uninstalled and the VF is disabled concurrently, akernel crash occurs. The reason is that the two actions call functionpci_disable_sriov(). The num_VFs is checked to determine whether torelease the corresponding resources. During the second calling, num_VFsis not 0 and the resource release function is called. However, thecorresponding resource has been released during the first invoking.Therefore, the problem occurs:[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020...[15278.131557][T50670] Call trace:[15278.134686][T50670] klist_put+0x28/0x12c[15278.138682][T50670] klist_del+0x14/0x20[15278.142592][T50670] device_del+0xbc/0x3c0[15278.146676][T50670] pci_remove_bus_device+0x84/0x120[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c[15278.162485][T50670] sriov_disable+0x50/0x11c[15278.166829][T50670] pci_disable_sriov+0x24/0x30[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3][15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge][15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30[15278.193848][T50670] invoke_syscall+0x50/0x11c[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164[15278.203837][T50670] do_el0_svc+0x34/0xcc[15278.207834][T50670] el0_svc+0x20/0x30For details, see the following figure. rmmod hclge disable VFs----------------------------------------------------hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock();In this patch, when driver is removing, we get the device_lock()to protect num_VFs, just like sriov_numvfs_store().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB dataIn case the non-paged data of a SKB carries protocol header and protocolpayload to be transmitted on a certain platform that the DMA AXI addresswidth is configured to 40-bit/48-bit, or the size of the non-paged datais bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXIaddress width is configured to 32-bit, then this SKB requires at leasttwo DMA transmit descriptors to serve it.For example, three descriptors are allocated to split one DMA buffermapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2].Then three elements of tx_q->tx_skbuff_dma[] will be allocated to holdextra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2].Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA bufferaddress returned by DMA mapping call. stmmac_tx_clean() will try tounmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].bufis a valid buffer address.The expected behavior that saves DMA buffer address of this non-pageddata to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL;On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by theDMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer addressobviously, then the DMA buffer will be unmapped immediately.There may be a rare case that the DMA engine does not finish thepending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will gohorribly wrong, DMA is going to access a unmapped/unreferenced memoryregion, corrupted data will be transmited or iommu fault will betriggered :(In contrast, the for-loop that maps SKB fragments behaves perfectlyas expected, and that is how the driver should do for both non-pageddata and paged frags actually.This patch corrects DMA map/unmap sequences by fixing the array indexfor tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.Tested and verified on DWXGMAC CORE 3.20a
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Fix KMSAN warning in decode_getfattr_attrs()Fix the following KMSAN warning:CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G BTainted: [B]=BAD_PAGEHardware name: QEMU Standard PC (Q35 + ICH9, 2009)==========================================================================================================BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe KMSAN warning is triggered in decode_getfattr_attrs(), when callingdecode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is notinitialized.Fix the issue by initializing fattr->mdsthreshold to NULL innfs_fattr_init().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LEThis aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4("Bluetooth: Always request for user confirmation for Just Works")always request user confirmation with confirm_hint set since thelikes of bluetoothd have dedicated policy around JUST_WORKS method(e.g. main.conf:JustWorksRepairing).CVE: CVE-2024-8805
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent NULL dereference in nfsd4_process_cb_update()@ses is initialized to NULL. If __nfsd4_find_backchannel() finds noavailable backchannel session, setup_callback_client() will try todereference @ses and segfault.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Filter invalid inodes with missing lookup functionAdd a check to the ovl_dentry_weird() function to prevent theprocessing of directory inodes that lack the lookup function.This is important because such inodes can cause errors in overlayfswhen passed to the lowerstack.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtc: check if __rtc_read_time was successful in rtc_timer_do_work()If the __rtc_read_time call fails,, the struct rtc_time tm; may containuninitialized data, or an illegal date/time read from the RTC hardware.When calling rtc_tm_to_ktime later, the result may be a very large value(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,they will continually expire, may causing kernel softlockup.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rdma/cxgb4: Prevent potential integer overflow on 32bitThe "gl->tot_len" variable is controlled by the user. It comes fromprocess_responses(). On 32bit systems, the "gl->tot_len + sizeof(structcpl_pass_accept_req) + sizeof(struct rss_header)" addition could have aninteger wrapping bug. Use size_add() to prevent this.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pps: Fix a use-after-freeOn a board running ntpd and gpsd, I'm seeing a consistent use-after-freein sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]---...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exceptionThis happens because pps_device_destruct() frees the pps_device with theembedded cdev immediately after calling cdev_del(), but, as the commentabove cdev_del() notes, fops for previously opened cdevs are stillcallable even after cdev_del() returns. I think this bug has alwaysbeen there: I can't explain why it suddenly started happening every timeI reboot this particular board.In commit d953e0e837e6 ("pps: Fix a use-after free bug whenunregistering a source."), George Spelvin suggested removing theembedded cdev. That seems like the simplest way to fix this, so I'veimplemented his suggestion, using __register_chrdev() with pps_idrbecoming the source of truth for which minor corresponds to whichdevice.But now that pps_idr defines userspace visibility instead of cdev_add(),we need to be sure the pps->dev refcount can't reach zero whileuserspace can still find it again. So, the idr_remove() call moves topps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix double free in error pathIf the uvc_status_init() function fails to allocate the int_urb, it willfree the dev->status pointer but doesn't reset the pointer to NULL. Thisresults in the kfree() call in uvc_status_cleanup() trying todouble-free the memory. Fix it by resetting the dev->status pointer toNULL after freeing it.Reviewed by: Ricardo Ribalda
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix NULL pointer dereference on certain command abortsIf a command is queued to the final usable TRB of a ring segment, theenqueue pointer is advanced to the subsequent link TRB and no further.If the command is later aborted, when the abort completion is handledthe dequeue pointer is advanced to the first TRB of the next segment.If no further commands are queued, xhci_handle_stopped_cmd_ring() seesthe ring pointers unequal and assumes that there is a pending command,so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbellring likely is unnecessary too, but it's harmless. Leave it alone.This is probably Bug 219532, but no confirmation has been received.The issue has been independently reproduced and confirmed fixed usinga USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.Everything continued working normally after several prevented crashes.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: fix out-of-bounds read during lookuplookup and resize can run in parallel.The xfrm_state_hash_generation seqlock ensures a retry, but the hashfunctions can observe a hmask value that is too large for the new hlistarray.rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {This is only safe in case the update to state_bydst is larger thannet->xfrm.xfrm_state_hmask (or if the lookup function getsserialized via state spinlock again).Fix this by prefetching state_hmask and the associated pointers.The xfrm_state_hash_generation seqlock retry will ensure that the pointerand the hmask will be consistent.The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,add lockdep assertions to document that they are only safe for insertside.xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.AFAICS this is an oversight from back when state lookup was converted toRCU, this lock should be replaced with RCU in a future patch.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: fix memory leaks and invalid access at probe error pathDeinitialize at reverse order when probe fails.When init_sw_vars fails, rtl_deinit_core should not be called, speciallynow that it destroys the rtl_wq workqueue.And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will beleaked.Remove pci_set_drvdata call as it will already be cleaned up by the coredriver code and could lead to memory leaks too. cf. commit 8d450935ae7f("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") andcommit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: prevent adding a device which is already a team device lowerPrevent adding a device which is already a team device lower,e.g. adding veth0 if vlan1 was already added and veth0 is a lower ofvlan1.This is not useful in practice and can lead to recursive locking:$ ip link add veth0 type veth peer name veth1$ ip link set veth0 up$ ip link set veth1 up$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1$ ip link add team0 type team$ ip link set veth0.1 down$ ip link set veth0.1 master team0team0: Port device veth0.1 added$ ip link set veth0 down$ ip link set veth0 master team0============================================WARNING: possible recursive locking detected6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted--------------------------------------------ip/7684 is trying to acquire lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)but task is already holding lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)other info that might help us debug this:Possible unsafe locking scenario:CPU0----lock(team->team_lock_key);lock(team->team_lock_key);*** DEADLOCK ***May be due to missing lock nesting notation2 locks held by ip/7684:stack backtrace:CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:122)print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? lock_acquire (kernel/locking/lockdep.c:5822)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? fib_sync_up (net/ipv4/fib_semantics.c:2167)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)__dev_notify_flags (net/core/dev.c:8993)? __dev_change_flags (net/core/dev.c:8975)dev_change_flags (net/core/dev.c:9027)vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)? br_device_event (net/bridge/br.c:143)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)dev_open (net/core/dev.c:1519 net/core/dev.c:1505)team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)do_set_master (net/core/rtnetlink.c:2917)do_setlink.isra.0 (net/core/rtnetlink.c:3117)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: remove unused check_buddy_privCommit 2461c7d60f9f ("rtlwifi: Update header file") introduced a globallist of private data structures.Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to matchvendor version 2013.02.07") started adding the private data to that list atprobe time and added a hook, check_buddy_priv to find the private data froma similar device.However, that function was never used.Besides, though there is a lock for that list, it is never used. And whenthe probe fails, the private data is never removed from the list. Thiswould cause a second probe to access freed memory.Remove the unused hook, structures and members, which will prevent thepotential race condition on the list and its corruption during a secondprobe when probe fails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()Explicitly verify the target vCPU is fully online _prior_ to clamping theindex in kvm_get_vcpu(). If the index is "bad", the nospec clamping willgenerate '0', i.e. KVM will return vCPU0 instead of NULL.In practice, the bug is unlikely to cause problems, as it will only comeinto play if userspace or the guest is buggy or misbehaving, e.g. KVM maysend interrupts to vCPU0 instead of dropping them on the floor.However, returning vCPU0 when it shouldn't exist per online_vcpus isproblematic now that KVM uses an xarray for the vCPUs array, as KVM needsto insert into the xarray before publishing the vCPU to userspace (seecommit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),i.e. before vCPU creation is guaranteed to succeed.As a result, incorrectly providing access to vCPU0 will trigger ause-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()bails out of vCPU creation due to an error and frees vCPU0. Commitafb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, butin doing so introduced an unsolvable teardown conundrum. Preventingaccesses to vCPU0 before it's fully online will allow reverting commitafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: don't allow reconnect after disconnectFollowing process can cause nbd_config UAF:1) grab nbd_config temporarily;2) nbd_genl_disconnect() flush all recv_work() and release theinitial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work)4) step 1) release the reference;5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAFFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), sothat nbd_genl_reconfigure() will fail.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: extend RCU protection in ndisc_send_skb()ndisc_send_skb() can be called without RTNL or RCU held.Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()and avoid a potential UAF.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: use RCU protection in ndisc_alloc_skb()ndisc_alloc_skb() can be called without RTNL or RCU being held.Add RCU protection to avoid possible UAF.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU protection in ip6_default_advmss()ip6_default_advmss() needs rcu protection to makesure the net structure it reads does not disappear.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: use RCU protection in __ip_rt_update_pmtu()__ip_rt_update_pmtu() must use RCU protection to makesure the net structure it reads does not disappear.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix oops when unload drivers parallelingWhen unload hclge driver, it tries to disable sriov first for eachae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver atthe time, because it removes all the ae_dev nodes, and it may causeoops.But we can't simply use hnae3_common_lock for this. Because in theprocess flow of pci_disable_sriov(), it will trigger the remove flowof VF, which will also take hnae3_common_lock.To fixes it, introduce a new mutex to protect the unload process.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi's weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi's weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: The sourceMapURL feature in devtools was missing security checks that would have allowed a webpage to attempt to include local files or other files that should have been inaccessible. This vulnerability affects Firefox < 99.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
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-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-Jinja2 > 0-0 (version in image is 2.8-22.11.1).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. 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 does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). 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:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Audit before 2.4.4 in Linux does not sanitize escape characters in filenames.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- audit > 0-0 (version in image is 2.8.1-10.14.1).
-
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:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-ply > 0-0 (version in image is 3.4-3.3.1).
-
Description: An uncontrolled resource consumption (memory leak) flaw was found in the ZeroMQ client in versions before 4.3.3 in src/pipe.cpp. This issue causes a client that connects to multiple malicious or compromised servers to crash. The highest threat from this vulnerability is to system availability.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libzmq3 > 0-0 (version in image is 4.0.4-15.8.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: fix possible use-after-free in transport error_recovery workWhile nvme_rdma_submit_async_event_work is checking the ctrl and queuestate before preparing the AER command and scheduling io_work, in orderto fully prevent a race where this check is not reliable the errorrecovery work must flush async_event_work before continuing to destroythe admin queue after setting the ctrl state to RESETTING such thatthere is no race .submit_async_event and the error recovery handleritself changing the ctrl state.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: fix shift-out-of-bounds in hid_report_raw_eventSyzbot reported shift-out-of-bounds in hid_report_raw_event.microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >32! (swapper/0)======================================================================UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20shift exponent 127 is too large for 32-bit type 'int'CPU: 0 PID: 0 Comm: swapper/0 Not tainted6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0Hardware name: Google Compute Engine/Google Compute Engine, BIOSGoogle 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107======================================================================If the size of the integer (unsigned n) is bigger than 32 in snto32(),shift exponent will be too large for 32-bit type 'int', resulting in ashift-out-of-bounds bug.Fix this by adding a check on the size of the integer (unsigned n) insnto32(). To add support for n greater than 32 bits, set n to 32, if nis greater than 32.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Prevent RSB underflow before vmenterOn VMX, there are some balanced returns between the time the guest'sSPEC_CTRL value is written, and the vmenter.Balanced returns (matched by a preceding call) are usually ok, but it'sat least theoretically possible an NMI with a deep call stack couldempty the RSB before one of the returns.For maximum paranoia, don't allow *any* returns (balanced or otherwise)between the SPEC_CTRL write and the vmenter. [ bp: Fix 32-bit build. ]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: sysstat through 12.7.2 allows a multiplication integer overflow in check_overflow in common.c. NOTE: this issue exists because of an incomplete fix for CVE-2022-39377.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- sysstat > 0-0 (version in image is 12.0.2-20.23.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in diAllocCurrently there is not check against the agno of the iag whileallocating new inodes to avoid fragmentation problem. Added the checkwhich is required.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: pca953x: fix pca953x_irq_bus_sync_unlock raceEnsure that `i2c_lock' is held when setting interrupt latch and mask inpca953x_irq_bus_sync_unlock() in order to avoid races.The other (non-probe) call site pca953x_gpio_set_multiple() ensures thelock is held before calling pca953x_write_regs().The problem occurred when a request raced against irq_bus_sync_unlock()approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid OOB when system.data xattr changes underneath the filesystemWhen looking up for an entry in an inlined directory, if e_value_offs ischanged underneath the filesystem by some change in the block device, itwill lead to an out-of-bounds access that KASAN detects as an UAF.EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.loop0: detected capacity change from 2048 to 2047==================================================================BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c: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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010aRAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27cR13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode withext4_get_inode_loc will lead to a check of the validity of the xattrs,avoiding this problem.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - add error check in the ahash_hmac_init functionThe ahash_init functions may return fails. The ahash_hmac_init shouldnot return ok when ahash_init returns error. For an example, ahash_initwill return -ENOMEM when allocation memory is error.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix freeing of the HMB descriptor tableThe HMB descriptor table is sized to the maximum number of descriptorsthat could be used for a given device, but __nvme_alloc_host_mem couldbreak out of the loop earlier on memory allocation failure and end upusing less descriptors than planned for, which leads to an incorrectsize passed to dma_free_coherent.In practice this was not showing up because the number of descriptorstends to be low and the dma coherent allocator always allocates andfrees at least a page.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: When curl is asked to use HSTS, the expiry time for a subdomain mightoverwrite a parent domain's cache entry, making it end sooner or later thanotherwise intended.This affects curl using applications that enable HSTS and use URLs with theinsecure `HTTP://` scheme and perform transfers with hosts like`x.example.com` as well as `example.com` where the first host is a subdomainof the second host.(The HSTS cache either needs to have been populated manually or there needs tohave been previous HTTPS accesses done as the cache needs to have entries forthe domains involved to trigger this problem.)When `x.example.com` responds with `Strict-Transport-Security:` headers, thisbug can make the subdomain's expiry timeout *bleed over* and get set for theparent domain `example.com` in curl's HSTS cache.The result of a triggered bug is that HTTP accesses to `example.com` getconverted to HTTPS for a different period of time than what was asked for bythe origin server. If `example.com` for example stops supporting HTTPS at itsexpiry time, curl might then fail to access `http://example.com` until the(wrongly set) timeout expires. This bug can also expire the parent's entry*earlier*, thus making curl inadvertently switch back to insecure HTTP earlierthan otherwise intended.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- curl > 0-0 (version in image is 8.0.1-11.108.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: cls_flow: validate TCA_FLOW_RSHIFT attributesyzbot found that TCA_FLOW_RSHIFT attribute was not validated.Right shitfing a 32bit integer is undefined for large shift values.UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: ipv6_addrconf addrconf_dad_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
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 >= 12-0 (version in image is 12-7.3.1).
- google-osconfig-agent > 0-0 (version in image is 20250416.02-1.41.1).
-
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent > 0-0 (version in image is 20250506.01-1.53.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: netem: account for backlog updates from child qdiscIn general, 'qlen' of any classful qdisc should keep track of thenumber of packets that the qdisc itself and all of its children holds.In case of netem, 'qlen' only accounts for the packets in its internaltfifo. When netem is used with a child qdisc, the child qdisc can use'qdisc_tree_reduce_backlog' to inform its parent, netem, about createdor dropped SKBs. This function updates 'qlen' and the backlog statisticsof netem, but netem does not account for changes made by a child qdisc.'qlen' then indicates the wrong number of packets in the tfifo.If a child qdisc creates new SKBs during enqueue and informs its parentabout this, netem's 'qlen' value is increased. When netem dequeues thenewly created SKBs from the child, the 'qlen' in netem is not updated.If 'qlen' reaches the configured sch->limit, the enqueue function stopsworking, even though the tfifo is not full.Reproduce the bug:Ensure that the sender machine has GSO enabled. Configure netem as rootqdisc and tbf as its child on the outgoing interface of the machineas follows:$ tc qdisc add dev root handle 1: netem delay 100ms limit 100$ tc qdisc add dev parent 1:0 tbf rate 50Mbit burst 1542 latency 50msSend bulk TCP traffic out via this interface, e.g., by running an iPerf3client on the machine. Check the qdisc statistics:$ tc -s qdisc show dev Statistics after 10s of iPerf3 TCP test before the fix (note thatnetem's backlog > limit, netem stopped accepting packets):qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0Statistics after the fix:qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.The interface fully stops transferring packets and "locks". In this case,the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is atits limit and no more packets are accepted.This patch adds a counter for the entries in the tfifo. Netem's 'qlen' isonly decreased when a packet is returned by its dequeue function, and notduring enqueuing into the child qdisc. External updates to 'qlen' are thusaccounted for and only the behavior of the backlog statistics changes. Asin other qdiscs, 'qlen' then keeps track of how many packets are held innetem and all of its children. As before, sch->limit remains as themaximum number of packets in the tfifo. The same applies to netem'sbacklog statistics.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: aqc111: Fix out-of-bounds accesses in RX fixupaqc111_rx_fixup() contains several out-of-bounds accesses that can betriggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data.Found doing variant analysis. Tested it with another driver (ax88179_178a), sinceI don't have a aqc111 device to test it, but the code looks very similar.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Scripting). Supported versions that are affected are Java SE: 8u221, 11.0.4 and 13; Java SE Embedded: 8u221. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 4.8 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: JSSE). Supported versions that are affected are Java SE: 11.0.5 and 13.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data as well as unauthorized read access to a subset of Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()Replace one-element array with a flexible-array member in `structmwifiex_ie_types_wildcard_ssid_params` to fix the following warningon a MT8173 Chromebook (mt8173-elm-hana):[ 356.775250] ------------[ cut here ]------------[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]The "(size 6)" above is exactly the length of the SSID of the networkthis device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len);There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on thisstruct, but it already didn't account for the size of the one-elementarray, so it doesn't need to be changed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2021-43389. Reason: This candidate is a reservation duplicate of CVE-2021-43389. Notes: All CVE users should reference CVE-2021-43389 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix kernel panic caused by race of smc_sockA crash occurs when smc_cdc_tx_handler() tries to access smc_sockbut smc_release() has already freed it.[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88[ 4570.696048] #PF: supervisor write access in kernel mode[ 4570.696728] #PF: error_code(0x0002) - not-present page[ 4570.697401] PGD 0 P4D 0[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30<...>[ 4570.711446] Call Trace:[ 4570.711746] [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0[ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560[ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10[ 4570.713489] tasklet_action_common.isra.17+0x66/0x140[ 4570.714083] __do_softirq+0x123/0x2f4[ 4570.714521] irq_exit_rcu+0xc4/0xf0[ 4570.714934] common_interrupt+0xba/0xe0Though smc_cdc_tx_handler() checked the existence of smc connection,smc_release() may have already dismissed and released the smc socketbefore smc_cdc_tx_handler() further visits it.smc_cdc_tx_handler() |smc_release()if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freedbh_lock_sock(&smc->sk) (panic) |To make sure we won't receive any CDC messages after we free thesmc_sock, add a refcount on the smc_connection for inflight CDCmessage(posted to the QP but haven't received related CQE), anddon't release the smc_connection until all the inflight CDC messageshaven been done, for both success or failed ones.Using refcount on CDC messages brings another problem: when the linkis going to be destroyed, smcr_link_clear() will reset the QP, whichthen remove all the pending CQEs related to the QP in the CQ. To makesure all the CQEs will always come back so the refcount on thesmc_connection can always reach 0, smc_ib_modify_qp_reset() was replacedby smc_ib_modify_qp_error().And remove the timeout in smc_wr_tx_wait_no_pending_sends() since weneed to wait for all pending WQEs done, or we may encounter use-after-free when handling CQEs.For IB device removal routine, we need to wait for all the QPs on thatdevice been destroyed before we can destroy CQs on the device, orthe refcount on smc_connection won't reach 0 and smc_sock cannot bereleased.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: make apf token non-zero to fix bugIn current async pagefault logic, when a page is ready, KVM relies onkvm_arch_can_dequeue_async_page_present() to determine whether to delivera READY event to the Guest. This function test token value of structkvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when aREADY event is finished by Guest. If value is zero meaning that a READYevent is done, so the KVM can deliver another.But the kvm_arch_setup_async_pf() may produce a valid token with zerovalue, which is confused with previous mention and may lead the loss ofthis READY event.This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_prot_sock.sysctl_ip_prot_sock is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_llm_reports.While reading sysctl_igmp_llm_reports, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hid: cp2112: Fix duplicate workqueue initializationPreviously the cp2112 driver called INIT_DELAYED_WORK withincp2112_gpio_irq_startup, resulting in duplicate initilizations of theworkqueue on subsequent IRQ startups following an initial request. Thisresulted in a warning in set_work_data in workqueue.c, as well as a rareNULL dereference within process_one_work in workqueue.c.Initialize the workqueue within _probe instead.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Fix null pointer dereference when host diesMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not raceand cause null pointer dereference when host suddenly dies.Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]virt device at the same time that xhci_kill_endpoint_urbs() tries toloop through all the device's endpoints, checking if there are anycancelled urbs left to give back.hold the xhci spinlock while freeing the virt device
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- pam > 0-0 (version in image is 1.1.8-24.77.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: lpi2c: Avoid calling clk_get_rate during transferInstead of repeatedly calling clk_get_rate for each transfer, lockthe clock rate and cache the value.A deadlock has been observed while adding tlv320aic32x4 audio codec tothe system. When this clock provider adds its clock, the clk mutex islocked already, it needs to access i2c, which in return needs the mutexfor clk_get_rate as well.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() when freeing tree block after errorWhen freeing a tree block, at btrfs_free_tree_block(), if we fail tocreate a delayed reference we don't deal with the error and just do aBUG_ON(). The error most likely to happen is -ENOMEM, and we have acomment mentioning that only -ENOMEM can happen, but that is not true,because in case qgroups are enabled any error returned frombtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returnedfrom btrfs_search_slot() for example) can be propagated back tobtrfs_free_tree_block().So stop doing a BUG_ON() and return the error to the callers and makethem abort the transaction to prevent leaking space. Syzbot wastriggering this, likely due to memory allocation failure injection.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Add missing bridge lock to pci_bus_lock()One of the true positives that the cfg_access_lock lockdep effortidentified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120Where pci_reset_bus() users are triggering unlocked secondary bus resets.Ironically pci_bus_reset(), several calls down from pci_reset_bus(), usespci_bus_lock() before issuing the reset which locks everything *but* thebridge itself.For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge);to pci_reset_function() for the "bus" and "cxl_bus" reset cases, addpci_dev_lock() for @bus->self to pci_bus_lock().[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfs: fix race between evice_inodes() and find_inode()&iput()Hi, allRecently I noticed a bug[1] in btrfs, after digged it intoand I believe it'a race in vfs.Let's assume there's a inode (ie ino 261) with i_count 1 iscalled by iput(), and there's a concurrent thread callinggeneric_shutdown_super().cpu0: cpu1:iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock()// note here: the inode 261// was still at sb list and hash list,// and I_FREEING|I_WILL_FREE was not been setbtrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEINGiput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()Now, we have two threads simultaneously evictingthe same inode, which may trigger the BUG(inode->i_state & I_CLEAR)statement both within clear_inode() and iput().To fix the bug, recheck the inode->i_count after holding i_lock.Because in the most scenarios, the first check is valid, andthe overhead of spin_lock() can be reduced.If there is any misunderstanding, please let me know, thanks.[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()return false when I reproduced the bug.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a NULL pointer dereference when failed to start a new trasacntion[BUG]Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[CAUSE]The allocation failure happens at the start_transaction() insideprepare_to_relocate(), and during the error handling we callunset_reloc_control(), which makes fs_info->balance_ctl to be NULL.Then we continue the error path cleanup in btrfs_balance() by callingreset_balance_state() which will call del_balance_item() to fully deletethe balance item in the root tree.However during the small window between set_reloc_contrl() andunset_reloc_control(), we can have a subvolume tree update and created areloc_root for that subvolume.Then we go into the final btrfs_commit_transaction() ofdel_balance_item(), and into btrfs_update_reloc_root() insidecommit_fs_roots().That function checks if fs_info->reloc_ctl is in the merge_reloc_treestage, but since fs_info->reloc_ctl is NULL, it results a NULL pointerdereference.[FIX]Just add extra check on fs_info->reloc_ctl insidebtrfs_update_reloc_root(), before checkingfs_info->reloc_ctl->merge_reloc_tree.That DEAD_RELOC_TREE handling is to prevent further modification to thereloc tree during merge stage, but since there is no reloc_ctl at all,we do not need to bother that.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix i_data_sem unlock order in ext4_ind_migrate()Fuzzing reports a possible deadlock in jbd2_log_wait_commit.This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to requiresynchronous updates because the file descriptor is opened with O_SYNC.This can lead to the jbd2_journal_stop() function callingjbd2_might_wait_for_commit(), potentially causing a deadlock if theEXT4_IOC_MIGRATE call races with a write(2) system call.This problem only arises when CONFIG_PROVE_LOCKING is enabled. In thiscase, the jbd2_might_wait_for_commit macro locks jbd2_handle in thejbd2_journal_stop function while i_data_sem is locked. This triggerslockdep because the jbd2_journal_start function might also lock the samejbd2_handle simultaneously.Found by Linux Verification Center (linuxtesting.org) with syzkaller.Rule: add
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Move events notifier registration to be after device registrationMove pkey change work initialization and cleanup from device resourcesstage to notifier stage, since this is the stage which handles this workevents.Fix a race between the device deregistration and pkey change work by movingMLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order toensure that the notifier is deregistered before the device during cleanup.Which ensures there are no works that are being executed after thedevice has already unregistered which can cause the panic below.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023Workqueue: events pkey_change_handler [mlx5_ib]RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]process_one_work+0x1e8/0x3c0worker_thread+0x50/0x3b0? rescuer_thread+0x380/0x380kthread+0x149/0x170? set_kthread_struct+0x50/0x50ret_from_fork+0x22/0x30Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]CR2: 0000000000000000---[ end trace f6f8be4eae12f7bc ]---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: IDLETIMER: Fix for possible ABBA deadlockDeletion of the last rule referencing a given idletimer may happen atthe same time as a read of its file in sysfs:| ======================================================| WARNING: possible circular locking dependency detected| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted| ------------------------------------------------------| iptables/3303 is trying to acquire lock:| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20|| but task is already holding lock:| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]|| which lock already depends on the new lock.A simple reproducer is:| #!/bin/bash|| while true; do| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| done &| while true; do| cat /sys/class/xt_idletimer/timers/testme >/dev/null| doneAvoid this by freeing list_mutex right after deleting the element fromthe list, then continuing with the teardown.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: util: Avoid accessing a ringbuffer not initialized yetIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer isfully initialized, we can hit the panic below:hv_utils: Registering HyperV Utility Driverhv_vmbus: registering driver hv_utils...BUG: kernel NULL pointer dereference, address: 0000000000000000CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1RIP: 0010:hv_pkt_iter_first+0x12/0xd0Call Trace:... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 asm_sysvec_hyperv_stimer0... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_readThis can happen because the KVP/VSS channel callback can be invokedeven before the channel is fully opened:1) as soon as hv_kvp_init() -> hvutil_transport_init() creates/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately andregister itself to the driver by writing a message KVP_OP_REGISTER1 to thefile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) andreading the file for the driver's response, which is handled byhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().2) the problem with kvp_register_done() is that it can cause thechannel callback to be called even before the channel is fully opened,and when the channel callback is starting to run, util_probe()->vmbus_open() may have not initialized the ringbuffer yet, so thecallback can hit the panic of NULL pointer dereference.To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in__vmbus_open(), just before the first hv_ringbuffer_init(), and then weunload and reload the driver hv_utils, and run the daemon manually withinthe 10 seconds.Fix the panic by reordering the steps in util_probe() so the char deventry used by the KVP or VSS daemon is not created until aftervmbus_open() has completed. This reordering prevents the race conditionfrom happening.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:leds: class: Protect brightness_show() with led_cdev->led_access mutexThere is NULL pointer issue observed if from Process A where hid devicebeing added which results in adding a led_cdev addition and later aanother call to access of led_cdev attribute from Process B can resultin NULL pointer issue.Use mutex led_cdev->led_access to protect access to led->cdev and itsattribute inside brightness_show() and max_brightness_show() and alsoupdate the comment for mutex that it should be used to protect the ledclass device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 3313.874301][ T4013] Mem abort info:[ 3313.874303][ T4013] ESR = 0x0000000096000006[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits[ 3313.874307][ T4013] SET = 0, FnV = 0[ 3313.874309][ T4013] EA = 0, S1PTW = 0[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault[ 3313.874313][ T4013] Data abort info:[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000..[ 3313.874332][ T4013] Dumping ftrace buffer:[ 3313.874334][ T4013] (ftrace buffer empty)....[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60[ 3313.874656][ T4013] sp : ffffffc0b910bbd0....[ 3313.874685][ T4013] Call trace:[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74[ 3313.874690][ T4013] brightness_show+0x20/0x4c[ 3313.874692][ T4013] dev_attr_show+0x38/0x74[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8[ 3313.874711][ T4013] ksys_read+0x78/0xe8[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c[ 3313.874718][ T4013] invoke_syscall+0x58/0x114[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28[ 3313.874727][ T4013] el0_svc+0x38/0x68[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Hold module reference while requesting a moduleUser space may unload ip_set.ko while it is itself requesting a set typebackend module, leading to a kernel crash. The race condition may beprovoked by inserting an mdelay() right after the nfnl_unlock() call.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: wl128x: Fix atomicity violation in fmc_send_cmd()Atomicity violation occurs when the fmc_send_cmd() function is executedsimultaneously with the modification of the fmdev->resp_skb value.Consider a scenario where, after passing the validity check within thefunction, a non-null fmdev->resp_skb variable is assigned a null value.This results in an invalid fmdev->resp_skb variable passing the validitycheck. As seen in the later part of the function, skb = fmdev->resp_skb;when the invalid fmdev->resp_skb passes the check, a null pointerdereference error may occur at line 478, evt_hdr = (void *)skb->data;To address this issue, it is recommended to include the validity check offmdev->resp_skb within the locked section of the function. Thismodification ensures that the value of fmdev->resp_skb does not changeduring the validation process, thereby maintaining its validity.This possible bug is found by an experimental static analysis tooldeveloped by our team. This tool analyzes the locking APIsto extract function pairs that can be concurrently executed, and thenanalyzes the instructions in the paired functions to identify possibleconcurrency bugs including data races and atomicity violations.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: make get_first_thin use rcu-safe list first functionThe documentation in rculist.h explains the absence of list_empty_rcu()and cautions programmers against relying on a list_empty() ->list_first() sequence in RCU safe code. This is because each of thesefunctions performs its own READ_ONCE() of the list head. This can leadto a situation where the list_empty() sees a valid list entry, but thesubsequent list_first() sees a different view of list head state after amodification.In the case of dm-thin, this author had a production box crash from a GPfault in the process_deferred_bios path. This function saw a valid listhead in get_first_thin() but when it subsequently dereferenced that andturned it into a thin_c, it got the inside of the struct pool, since thelist was now empty and referring to itself. The kernel on which thisoccurred printed both a warning about a refcount_t being saturated, anda UBSAN error for an out-of-bounds cpuid access in the queued spinlock,prior to the fault itself. When the resulting kdump was examined, itwas possible to see another thread patiently waiting in thin_dtr'ssynchronize_rcu.The thin_dtr call managed to pull the thin_c out of the active thinslist (and have it be the last entry in the active_thins list) at justthe wrong moment which lead to this crash.Fortunately, the fix here is straight forward. Switch get_first_thin()function to use list_first_or_null_rcu() which performs just a singleREAD_ONCE() and returns NULL if the list is already empty.This was run against the devicemapper test suite's thin-provisioningsuites for delete and suspend and no regressions were observed.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: always recalculate features after XDP clearing, fix null-derefRecalculate features when XDP is detached.Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: onThe fact that HW-GRO doesn't get re-enabled automatically is justa minor annoyance. The real issue is that the features will randomlycome back during another reconfiguration which just happens to invokenetdev_update_features(). The driver doesn't handle reconfiguringtwo things at a time very robustly.Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") we only reconfigure the RSS hash tableif the "effective" number of Rx rings has changed. If HW-GRO isenabled "effective" number of rings is 2x what user sees.So if we are in the bad state, with HW-GRO re-enablement "pending"after XDP off, and we lower the rings by / 2 - the HW-GRO ringsdoing 2x and the ethtool -L doing / 2 may cancel each other out,and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings &&condition in __bnxt_reserve_rings() will be false.The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0As we try to access a freed ring.The issue is present since XDP support was added, really, butprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") it wasn't causing major issues.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can'tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm->nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1("cdc-acm: reassemble fragmented notifications").A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device's vendor/product IDs andits other interfaces.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: xmit: make sure we have at least eth header len bytessyzbot triggered an uninit value[1] error in bridge device's xmit pathby sending a short (less than ETH_HLEN bytes) skb. To fix it check ifwe can actually pull that amount instead of assuming.Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL[1]BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __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+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 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
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix list corruption in perf_cgroup_switch()There's list corruption on cgrp_cpuctx_list. This happens on thefollowing path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the listUse list_for_each_entry_safe() to allow removing an entry duringiteration.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: fix memory corruption when tag_size is less than digest sizeIt is possible to set up dm-integrity in such a way that the"tag_size" parameter is less than the actual digest size. In thissituation, a part of the digest beyond tag_size is ignored.In this case, dm-integrity would write beyond the end of theic->recalc_tags array and corrupt memory. The corruption happened inintegrity_recalc->integrity_sector_checksum->crypto_shash_final.Fix this corruption by increasing the tags array so that it has enoughpadding at the end to accomodate the loop in integrity_recalc() beingable to write a full digest size for the last member of the tagsarray.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
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:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Avoid out of bounds access when parsing _CPC dataIf the NumEntries field in the _CPC return package is less than 2, donot attempt to access the "Revision" element of that package, becauseit may not be present then.BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: prevent potential string overflowThe dev->id value comes from ida_alloc() so it's a number between zeroand INT_MAX. If it's too high then these sprintf()s will overflow.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Lock external INTx masking opsMask operations through config space changes to DisINTx may race INTxconfiguration changes via ioctl. Create wrappers that add locking forpaths outside of the core interrupt code.In particular, irq_type is updated holding igate, therefore testingis_intx() requires holding igate. For example clearing DisINTx fromconfig space can otherwise race changes of the interrupt configuration.This aligns interfaces which may trigger the INTx eventfd into twocamps, one side serialized by igate and the other only enabled whileINTx is configured. A subsequent patch introduces synchronization forthe latter flows.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binariesThe allocation failure of mycs->yuv_scaler_binary in load_video_binaries()is followed with a dereference of mycs->yuv_scaler_binary after thefollowing call chain:sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()In unload_video_binaries(), it calls to ia_css_binary_unload with argument&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to thesame memory slot as mycs->yuv_scaler_binary. Thus, a null-pointerdereference is triggered.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prefer nft_chain_validatenft_chain_validate already performs loop detection because a cycle willresult in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).It also follows maps via ->validate callback in nft_lookup, so thereappears no reason to iterate the maps again.nf_tables_check_loops() and all its helper functions can be removed.This improves ruleset load time significantly, from 23s down to 12s.This also fixes a crash bug. Old loop detection code can result inunbounded recursion:BUG: TASK stack guard page was hit at ....Oops: stack guard page: 0000 [#1] PREEMPT SMP KASANCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1[..]with a suitable ruleset during validation of register stores.I can't see any actual reason to attempt to check for this fromnft_validate_register_store(), at this point the transaction is still inprogress, so we don't have a full picture of the rule graph.For nf-next it might make sense to either remove it or make this dependon table->validate_state in case we could catch an error earlier(for improved error reporting to userspace).
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end ofa line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer atthe specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Mark XDomain as unplugged when router is removedI noticed that when we do discrete host router NVM upgrade and it getshot-removed from the PCIe side as a result of NVM firmware authentication,if there is another host connected with enabled paths we hang in tearingthem down. This is due to fact that the Thunderbolt networking driveralso tries to cleanup the paths and ends up blocking intb_disconnect_xdomain_paths() waiting for the domain lock.However, at this point we already cleaned the paths in tb_stop() sothere is really no need for tb_disconnect_xdomain_paths() to do thatanymore. Furthermore it already checks if the XDomain is unplugged andbails out early so take advantage of that and mark the XDomain asunplugged when we remove the parent router.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of/irq: Prevent device address out-of-bounds read in interrupt map walkWhen of_irq_parse_raw() is invoked with a device address smaller thanthe interrupt parent node (from #address-cells property), KASAN detectsthe following out-of-bounds read when populating the initial match table(dyndbg="func of_irq_parse_* +p"): OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764 CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ... The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680) The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it !Prevent the out-of-bounds read by copying the device address into abuffer of sufficient size.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: Guard against bad data for ATIF ACPI methodIf a BIOS provides bad data in response to an ATIF method callthis causes a NULL pointer dereference in the caller.```? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)? exc_page_fault (arch/x86/mm/fault.c:1542)? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu```It has been encountered on at least one system, so guard for it.(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:initramfs: avoid filename buffer overrunThe initramfs filename field is defined inDocumentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== =========================... 70 c_namesize 8 bytes Length of filename, including final \0When extracting an initramfs cpio archive, the kernel's do_name() pathhandler assumes a zero-terminated path at @collected, passing itdirectly to filp_open() / init_mkdir() / init_mknod().If a specially crafted cpio entry carries a non-zero-terminated filenameand is followed by uninitialized memory, then a file may be created withtrailing characters that represent the uninitialized memory. The abilityto create an initramfs entry would imply already having full control ofthe system, so the buffer overrun shouldn't be considered a securityvulnerability.Append the output of the following bash script to an existing initramfsand observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfsIt's easiest to observe non-zero uninitialized memory when the output isgzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),rather than the initrd_start+initrd_size block.---- reproducer.sh ----nilchar="A" # change to "\0" to properly zero terminate / padmagic="070701"ino=1mode=$(( 0100777 ))uid=0gid=0nlink=1mtime=1filesize=0devmajor=0devminor=1rdevmajor=0rdevminor=0csum=0fname="initramfs_test_fname_overrun"namelen=$(( ${#fname} + 1 )) # plus one to account for terminatorprintf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fnametermpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))printf "%.s${nilchar}" $(seq 1 $termpadlen)---- reproducer.sh ----Symlink filename fields handled in do_symlink() won't overrun past thedata segment, due to the explicit zero-termination of the symlinktarget.Fix filename buffer overrun by aborting the initramfs FSM if any cpioentry doesn't carry a zero-terminator at the expected (name_len - 1)offset.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ts2020: fix null-ptr-deref in ts2020_probe()KASAN reported a null-ptr-deref issue when executing the followingcommand: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...The cause of the problem is that when using sysfs to dynamically registeran i2c device, there is no platform data, but the probe process of ts2020needs to use platform data, resulting in a null pointer being accessed.Solve this problem by adding checks to platform data.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: avoid NULL pointer error during sdio removeWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdioworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ONis set to yes, kernel panic will happen:Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2cThis is because during 'rmmod ath10k', ath10k_sdio_remove() will callath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()will finally be called in ath10k_core_destroy(). This function will freestruct cfg80211_registered_device *rdev and all its members, includingwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdioworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.After device release, destroy_workqueue() will use NULL pointer then thekernel panic happen.Call trace:ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueueNeed to call destroy_workqueue() before ath10k_core_destroy(), freethe work queue buffer first and then free pointer of work queue byath10k_core_destroy(). This order matches the error path order inath10k_sdio_probe().No work will be queued on sdio workqueue between it is destroyed andath10k_core_destroy() is called. Based on the call_stack above, thereason is:Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() andath10k_sdio_irq_disable() will queue work on sdio workqueue.Sleep timer will be deleted before ath10k_core_destroy() inath10k_hif_power_down().ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().ath10k_core_unregister() will call ath10k_hif_power_down() to stop hifbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Due to a layout change, iframe contents could have been rendered outside of its border. This could have led to user confusion or spoofing attacks. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: In unusual circumstances, selecting text could cause text selection caching to behave incorrectly, leading to a crash. This vulnerability affects Firefox < 99.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: A website that had permission to access the microphone could record audio without the audio notification being shown. This bug does not allow the attacker to bypass the permission prompt - it only affects the notification shown once permission has been granted.
*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 104.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: regex is an implementation of regular expressions for the Rust language. The regex crate features built-in mitigations to prevent denial of service attacks caused by untrusted regexes, or untrusted input matched by trusted regexes. Those (tunable) mitigations already provide sane defaults to prevent attacks. This guarantee is documented and it's considered part of the crate's API. Unfortunately a bug was discovered in the mitigations designed to prevent untrusted regexes to take an arbitrary amount of time during parsing, and it's possible to craft regexes that bypass such mitigations. This makes it possible to perform denial of service attacks by sending specially crafted regexes to services accepting user-controlled, untrusted regexes. All versions of the regex crate before or equal to 1.5.4 are affected by this issue. The fix is include starting from regex 1.5.5. All users accepting user-controlled regexes are recommended to upgrade immediately to the latest version of the regex crate. Unfortunately there is no fixed set of problematic regexes, as there are practically infinite regexes that could be crafted to exploit this vulnerability. Because of this, it us not recommend to deny known problematic regexes.
Packages affected:
- mozilla-nss > 0-0 (version in image is 3.112-58.130.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
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:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ruby2.1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Add poll mod list filling checkIn case of im_protocols value is 1 and tm_protocols value is 0 thiscombination successfully passes the check'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().But then after pn533_poll_create_mod_list() call in pn533_start_poll()poll mod list will remain empty and dev->poll_mod_count will remain 0which lead to division by zero.Normally no im protocol has value 1 in the mask, so this combination isnot expected by driver. But these protocol values actually come fromuserspace via Netlink interface (NFC_CMD_START_POLL operation). So abroken or malicious program may pass a message containing a "bad"combination of protocol parameter values so that dev->poll_mod_countis not incremented inside pn533_poll_create_mod_list(), thus leadingto division by zero.Call trace looks like:nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll()Add poll mod list filling check.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Deployment). The supported version that is affected is Java SE: 8u221; Java SE Embedded: 8u221. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.0 Base Score 4.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock between quota disable and qgroup rescan workerQuota disable ioctl starts a transaction before waiting for the qgrouprescan worker completes. However, this wait can be infinite and resultsin deadlock because of circular dependency among the quota disableioctl, the qgroup rescan worker and the other task with transaction suchas block group relocation task.The deadlock happens with the steps following:1) Task A calls ioctl to disable quota. It starts a transaction and waits for qgroup rescan worker completes.2) Task B such as block group relocation task starts a transaction and joins to the transaction that task A started. Then task B commits to the transaction. In this commit, task B waits for a commit by task A.3) Task C as the qgroup rescan worker starts its job and starts a transaction. In this transaction start, task C waits for completion of the transaction that task A started and task B committed.This deadlock was found with fstests test case btrfs/115 and a zonednull_blk device. The test case enables and disables quota, and theblock group reclaim was triggered during the quota disable by chance.The deadlock was also observed by running quota enable and disable inparallel with 'btrfs balance' command on regular null_blk devices.An example report of the deadlock: [372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds. [372.479944] Not tainted 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000 [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Call Trace: [372.514092] [372.521684] __schedule+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] schedule+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? finish_wait+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960] ? do_raw_spin_lock+0x11e/0x250 [372.627137] ? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] worker_thread+0x59e/0xf90 [372.676172] ? process_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds. [372.729827] Not tainted 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000 [372.787776] Call Trace: [372.801652] [372.812961] __schedule+0xb56/0x4850 [372.830011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] schedule+0xe0/0x270 [372.901685] wait_current_trans+0x22c/0x310 [btrfs] [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs] [372.938923] ? finish_wait+0x270/0x270 [372.959085] ? join_transaction+0xc7---truncated---
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: aead,cipher - zeroize key buffer after useI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holdingcryptographic information should be zeroized once they are no longerneeded. Accomplish this by using kfree_sensitive for buffers thatpreviously held the private key.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: check device is present when getting link settingsA sysfs reader can race with a device reset or removal, attempting toread device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5,state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).The device is not present, note lack of __LINK_STATE_PRESENT (0b10).This is the same sort of panic as observed in commit 4224cfd7fb65("net-sysfs: add check for netdevice being present to speed_show").There are many other callers of __ethtool_get_link_ksettings() whichdon't have a device presence check.Move this check into ethtool to protect all callers.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesA bogus device can provide a bNumConfigurations value that exceeds theinitial value used in usb_get_configuration for allocating dev->config.This can lead to out-of-bounds accesses later, e.g. inusb_destroy_configuration.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: systemport: fix potential memory leak in bcm_sysport_xmit()The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skbin case of dma_map_single() fails, add dev_kfree_skb() to fix it.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Vim is an open source, command line text editor. A use-after-free was found in Vim < 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 11.0.4 and 13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.0 Base Score 4.8 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 11.0.4 and 13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 7u231, 8u221, 11.0.4 and 13; Java SE Embedded: 8u221. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.0 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Security). Supported versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231. Difficult to exploit vulnerability allows unauthenticated attacker with network access via Kerberos to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), 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.0 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
Packages affected:
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
-
Description: The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: staging: media: zoran: move videodev allocMove some code out of zr36057_init() and create new functions for handlingzr->video_dev. This permit to ease code reading and fix a zr->video_devmemory leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/plane: Move range check for format_count earlierWhile the check for format_count > 64 in __drm_universal_plane_init()shouldn't be hit (it's a WARN_ON), in its current position it will thenleak the plane->format_types array and fail to calldrm_mode_object_unregister() leaking the modeset identifier. Move it tothe start of the function to avoid allocating those resources in thefirst place.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix leaking sent_cmd skbsent_cmd memory is not freed before freeing hci_dev causing it to leakit contents.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix PCI device refcount leak in has_external_pci()for_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() before 'return true' to avoid reference count leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix leak of nested actionsWhile parsing user-provided actions, openvswitch module may dynamicallyallocate memory and store pointers in the internal copy of the actions.So this memory has to be freed while destroying the actions.Currently there are only two such actions: ct() and set(). However,there are many actions that can hold nested lists of actions andovs_nla_free_flow_actions() just jumps over them leaking the memory.For example, removal of the flow with the following actions will leadto a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0)Non-freed set() action may also leak the 'dst' structure for thetunnel info including device references.Under certain conditions with a high rate of flow rotation that maycause significant memory leak problem (2MB per second in reporter'scase). The problem is also hard to mitigate, because the user doesn'thave direct control over the datapath flows generated by OVS.Fix that by iterating over all the nested actions and freeingeverything that needs to be freed recursively.New build time assertion should protect us from this problem if newactions will be added in the future.Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so allattributes has to be explicitly checked. sample() and clone() actionsare mixing extra attributes into the user-provided action list. Thatprevents some code generalization too.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/iommu: Add missing of_node_put in iommu_init_early_dartThe device_node pointer is returned by of_find_compatible_nodewith refcount incremented. We should use of_node_put() to avoidthe refcount leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: mxs-auart: add spinlock around changing cts stateThe uart_handle_cts_change() function in serial_core expects the callerto hold uport->lock. For example, I have seen the below kernel splat,when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: check A-MSDU format more carefullyIf it looks like there's another subframe in the A-MSDUbut the header isn't fully there, we can end up readingdata out of bounds, only to discard later. Make this abit more careful and check if the subframe header caneven be present.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: don't walk off the end of a directory data blockThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entryto make sure don't stray beyond valid memory region. Before patching, theloop simply checks that the start offset of the dup and dep is within therange. So in a crafted image, if last entry is xfs_dir2_data_unused, wecan change dup->length to dup->length-1 and leave 1 byte of space. In thenext traversal, this space will be considered as dup or dep. We mayencounter an out of bound read when accessing the fixed members.In the patch, we make sure that the remaining bytes large enough to holdan unused entry before accessing xfs_dir2_data_unused andxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also makesure that the remaining bytes large enough to hold a dirent with asingle-byte name before accessing xfs_dir2_data_entry.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix overflow in get_free_elt()"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.Once it overflows, new elements can still be inserted into the tracing_mapeven though the maximum number of elements (`max_elts`) has been reached.Continuing to insert elements after the overflow could result in thetracing_map containing "tracing_map->max_size" elements, leaving no emptyentries.If any attempt is made to insert an element into a full tracing_map using`__tracing_map_insert()`, it will cause an infinite loop with preemptiondisabled, leading to a CPU hang problem.Fix this by preventing any further increments to "tracing_map->next_elt"once it reaches "tracing_map->max_elt".
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: disallow setting special AP channel widthsSetting the AP channel width is meant for use with the normal20/40/... MHz channel width progression, and switching aroundin S1G or narrow channels isn't supported. Disallow that.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedNot doing so will make us send a host command to the transport while thefirmware is not alive, which will trigger a WARNING.bad state = 0WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]Call Trace: iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: call cache_put if xdr_reserve_space returns NULLIf not enough buffer space available, but idmap_lookup has triggeredlookup_fn which calls cache_get and returns successfully. Then wemissed to call cache_put here which pairs with cache_get.Reviwed-by: Jeff Layton
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Fix memory leak in management txIn the current logic, memory is allocated for storing the MSDU contextduring management packet TX but this memory is not being freed duringmanagement TX completion. Similar leaks are seen in the management TXcleanup logic.Kmemleak reports this problem as below,unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20Free the memory during completion and cleanup to fix the leak.Protect the mgmt_pending_tx idr_remove() operation inath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar toother instances.Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Endless recursion exists in xkbcomp/expr.c in xkbcommon and libxkbcommon before 0.8.1, which could be used by local attackers to crash xkbcommon users by supplying a crafted keymap file that triggers boolean negation.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage in xkbcommon before 0.8.1 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because geometry tokens were desupported incorrectly.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage in xkbcommon before 0.8.1 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because the XkbFile for an xkb_geometry section was mishandled.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: An infinite loop when reaching EOL unexpectedly in compose/parser.c (aka the keymap parser) in xkbcommon before 0.8.1 could be used by local attackers to cause a denial of service during parsing of crafted keymap files.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: An invalid free in ExprAppendMultiKeysymList in xkbcomp/ast-build.c in xkbcommon before 0.8.1 could be used by local attackers to crash xkbcommon keymap parsers or possibly have unspecified other impact by supplying a crafted keymap file.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage when handling invalid aliases in CopyKeyAliasesToKeymap in xkbcomp/keycodes.c in xkbcommon before 0.8.1 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage when parsing invalid atoms in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because lookup failures are mishandled.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file that triggers an xkb_intern_atom failure.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage in LookupModMask in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file with invalid virtual modifiers.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage in ResolveStateAndPredicate in xkbcomp/compat.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file with a no-op modmask expression.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: Unchecked NULL pointer usage in resolve_keysym in xkbcomp/parser.y in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because a map access attempt can occur for a map that was never created.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- xkbcomp > 0-0 (version in image is 1.2.4-9.59).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()for_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() for the error path to avoid reference count leak.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: Fix a potential socket leak in p9_socket_openBoth p9_fd_create_tcp() and p9_fd_create_unix() will callp9_socket_open(). If the creation of p9_trans_fd fails,p9_fd_create_tcp() and p9_fd_create_unix() will return anerror directly instead of releasing the cscoket, which willresult in a socket leak.This patch adds sock_release() to fix the leak issue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence objThis issue takes place in an error path inamdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls intodefault case, the function simply returns -EINVAL, forgetting todecrement the reference count of a dma_fence obj, which is bumpedearlier by amdgpu_cs_get_fence(). This may result in reference countleaks.Fix it by decreasing the refcount of specific object before returningthe error code.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sfp: fix memory leak in sfp_probe()sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). Whendevm_add_action() fails, sfp is not freed, which leads to a memory leak.We should use devm_add_action_or_reset() instead of devm_add_action().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix possible refcount leak in tipc_sk_create()Free sk in case tipc_sk_insert() fails.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferredSimilar to the handling of play_deferred in commit 19cfe912c37b("Bluetooth: btusb: Fix memory leak in play_deferred"), we thoughta patch might be needed here as well.Currently usb_submit_urb is called directly to submit deferred txurbs after unanchor them.So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urband cause memory leak.Put those urbs in tx_anchor to avoid the leak, and also fix the errorhandling.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: us122l: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.The loop of us122l->mmap_count check is dropped as well. The check isuseless for the asynchronous operation with *_when_closed().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usx2y: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix memory leak in dccp_feat_change_recvIf dccp_feat_push_confirm() fails after new value for SP feature was acceptedwithout reconciliation ('entry == NULL' branch), memory allocated for that valuewith dccp_feat_clone_sp_val() is never freed.Here is the kmemleak stack for this:unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1Clean up the allocated memory in case of dccp_feat_push_confirm() failureand bail out with an error reset code.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: emux: improve patch ioctl data validationIn load_data(), make the validation of and skipping over the main infoblock match that in load_guspatch().In load_guspatch(), add checking that the specified patch length matchesthe actually supplied data, like load_data() already did.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: There is a LOW severity vulnerability affecting CPython, specifically the'http.cookies' standard library module.When parsing cookies that contained backslashes for quoted characters inthe cookie value, the parser would use an algorithm with quadraticcomplexity, resulting in excess CPU resources being used while parsing thevalue.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races in unix_release_sock/unix_stream_sendmsgA data-race condition has been identified in af_unix. In one data path,the write function unix_release_sock() atomically writes tosk->sk_shutdown using WRITE_ONCE. However, on the reader side,unix_stream_sendmsg() does not read it atomically. Consequently, thisissue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")addressed a comparable issue in the past regarding sk->sk_shutdown.However, it overlooked resolving this particular data path.This patch only offending unix_stream_sendmsg() function, since theother reads seem to be protected by unix_state_lock() as discussed in
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "Revert "block, bfq: honor already-setup queue merges""A crash [1] happened to be triggered in conjunction with commit2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). Thelatter was then reverted by commit ebc69e897e17 ("Revert "block, bfq:honor already-setup queue merges""). Yet, the reverted commit was notthe one introducing the bug. In fact, it actually triggered a UAFintroduced by a different commit, and now fixed by commit d29bd41428cf("block, bfq: reset last_bfqq_created on group change").So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq:honor already-setup queue merges") out. This commit restores it.[1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: clear PARENT_WATCHED flags lazilyIn some setups directories can have many (usually negative) dentries.Hence __fsnotify_update_child_dentry_flags() function can take asignificant amount of time. Since the bulk of this function happensunder inode->i_lock this causes a significant contention on the lockwhen we remove the watch from the directory as the__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()races with __fsnotify_update_child_dentry_flags() calls from__fsnotify_parent() happening on children. This can lead upto softlockupreports reported by users.Fix the problem by calling fsnotify_update_children_dentry_flags() toset PARENT_WATCHED flags only when parent starts watching children.When parent stops watching children, clear false positive PARENT_WATCHEDflags lazily in __fsnotify_parent() for each accessed child.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ipv6: release expired exception dst cached in socketDst objects get leaked in ip6_negative_advice() when this function isexecuted for an expired IPv6 route located in the exception table. Thereare several conditions that must be fulfilled for the leak to occur:* an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created* a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions* after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dstWhen TCP executes ip6_negative_advice() for an exception dst that hasexpired and if no other socket holds a reference to the exception dst, therefcount of the exception dst is 2, which corresponds to the incrementmade by dst_init() and the increment made by the TCP socket for which theconnection is timing out. The refcount made by the socket is neverreleased. The refcount of the dst is decremented in sk_dst_reset() butthat decrement is counteracted by a dst_hold() intentionally placed justbefore the sk_dst_reset() in ip6_negative_advice(). Afterip6_negative_advice() has finished, there is no other object tied to thedst. The socket lost its reference stored in sk_dst_cache and the dst isno longer in the exception table. The exception dst becomes a leakedobject.As a result of this dst leak, an unbalanced refcount is reported for theloopback device of a net namespace being destroyed under kernels that donot contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):unregister_netdevice: waiting for lo to become free. Usage count = 2Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). Thepatch that introduced the dst_hold() in ip6_negative_advice() was92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22merely refactored the code with regards to the dst refcount so the issuewas present even before 92f1655aa2b22. The bug was introduced in54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actuallyexpired.") where the expired cached route is deleted and the sk_dst_cachemember of the socket is set to NULL by calling dst_negative_advice() butthe refcount belonging to the socket is left unbalanced.The IPv4 version - ipv4_negative_advice() - is not affected by this bug.When the TCP connection times out ipv4_negative_advice() merely resets thesk_dst_cache of the socket while decrementing the refcount of theexception dst.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (adc128d818) Fix underflows seen when writing limit attributesDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a largenegative number such as -9223372036854775808 is provided by the user.Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kexec: fix memory leak of elf header bufferThis is reported by kmemleak detector:unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xaeIn crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() tostore elf headers. While it's not freed back to system correctly whenkdump kernel is reloaded or unloaded. Then memory leak is caused. Fix itby introducing x86 specific function arch_kimage_file_post_load_cleanup(),and freeing the buffer there.And also remove the incorrect elf header buffer freeing code. Beforecalling arch specific kexec_file loading function, the image instance hasbeen initialized. So 'image->elf_headers' must be NULL. It doesn't makesense to free the elf header buffer in the place.Three different people have reported three bugs about the memory leak onx86_64 inside Redhat.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: Unspecified vulnerability in Oracle Java SE 7u80 allows remote attackers to affect integrity via unknown vectors related to Hotspot.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: Unspecified vulnerability in Oracle Java SE 7u80 and 8u45 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Install.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: Unspecified vulnerability in Oracle Java SE 6u95, 7u80, and 8u45 allows remote attackers to affect confidentiality via unknown vectors related to installation.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: Unspecified vulnerability in Oracle Java SE 6u95, 7u80, and 8u45, and Java SE Embedded 7u75 and 8u33 allows remote attackers to affect confidentiality, integrity, and availability via vectors related to CORBA.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: Unspecified vulnerability in Oracle Java SE 8u45 and Java SE Embedded 8u33 allows remote attackers to affect availability via unknown vectors related to Security.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: Unspecified vulnerability in Oracle Java SE 7u80 and 8u45 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Deployment.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- java-1_7_1-ibm > 0-0 (version in image is 1.7.1_sr5.15-38.77.1).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2015-7703. Reason: This candidate is a reservation duplicate of CVE-2015-7703. Notes: All CVE users should reference CVE-2015-7703 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- ntp > 0-0 (version in image is 4.2.8p17-106.7.1).
-
Description: The big2_toUtf8 function in lib/xmltok.c in libexpat in Expat 2.0.1, as used in the XML-Twig module for Perl, allows context-dependent attackers to cause a denial of service (application crash) via an XML document with malformed UTF-8 sequences that trigger a buffer over-read, related to the doProlog function in lib/xmlparse.c, a different vulnerability than CVE-2009-2625 and CVE-2009-3720.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: The ssl_get_algorithm2 function in ssl/s3_lib.c in OpenSSL before 1.0.2 obtains a certain version number from an incorrect data structure, which allows remote attackers to cause a denial of service (daemon crash) via crafted traffic from a TLS 1.2 client.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: The DTLS retransmission implementation in OpenSSL 1.0.0 before 1.0.0l and 1.0.1 before 1.0.1f does not properly maintain data structures for digest and encryption contexts, which might allow man-in-the-middle attackers to trigger the use of a different context and cause a denial of service (application crash) by interfering with packet delivery, related to ssl/d1_both.c and ssl/t1_enc.c.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: ssl/s3_clnt.c in OpenSSL 1.0.0 before 1.0.0t, 1.0.1 before 1.0.1p, and 1.0.2 before 1.0.2d, when used for a multi-threaded client, writes the PSK identity hint to an incorrect data structure, which allows remote servers to cause a denial of service (race condition and double free) via a crafted ServerKeyExchange message.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- libopenssl0_9_8 > 0-0 (version in image is 0.9.8j-106.64.1).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-11543. Reason: This candidate is a duplicate of CVE-2017-11543. Notes: All CVE users should reference CVE-2017-11543 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- tcpdump > 0-0 (version in image is 4.9.2-14.20.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fixmap: Fix VM debug warning on unmapUnmapping a fixmap entry is done by calling __set_fixmap()with FIXMAP_PAGE_CLEAR as flags.Today, powerpc __set_fixmap() calls map_kernel_page().map_kernel_page() is not happy when called a second timefor the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 NIP [c0017cd4] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Call Trace: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable) [e1011e30] [c0165fec] __set_fixmap+0x30/0x44 [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030Implement unmap_kernel_page() which clears an existing pte.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- kernel-default > 0-0 (version in image is 4.12.14-122.272.1).
-
Description: The resolve_redirects function in sessions.py in requests 2.1.0 through 2.5.3 allows remote attackers to conduct session fixation attacks via a cookie without a host value in a redirect.
Packages affected:
- SLES_SAP-release == 12.5 (version in image is 12.5-1.130).
- python-requests > 0-0 (version in image is 2.24.0-8.23.1).