-
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:
- sle-module-adv-systems-management-release >= 12-0 (version in image is 12-4.3.1).
- python-requests > 0-0 (version in image is 2.24.0-8.23.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: The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: When a non-x86 platform is detected, cloud-init grants root access to a hardcoded url with a local IP address. To prevent this, cloud-init default configurations disable platform enumeration.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- cloud-init > 0-0 (version in image is 20.2-37.57.1).
-
Description: Memory safety bugs present in Firefox 141 and Thunderbird 141. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 142 and Thunderbird < 142.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- mozilla-nss-certs < 3.112.2-58.133.1 (version in image is 3.112-58.130.1).
-
Description: named in ISC BIND 9.x before 9.9.8-P4 and 9.10.x before 9.10.3-P4 allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a crafted signature record for a DNAME record, related to db.c and resolver.c.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.60.2).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- bind-utils < 9.11.22-3.65.1 (version in image is 9.11.22-3.60.2).
-
Description: Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.158.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-release == 12.5 (version in image is 12.5-9.5.2).
- ruby > 0-0 (version in image is 2.1-1.6).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.158.1).
-
Description: Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.158.1).
-
Description: When using a TarFile.errorlevel = 0 and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0 in affected versions is that the member would still be extracted and not skipped.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.158.1).
-
Description: The email module, specifically the "BytesGenerator" class, didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. This is only applicable if using "LiteralHeader" writing headers that don't respect email folding rules, the new behavior will reject the incorrectly folded headers in "BytesGenerator".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools < 2.48.2-12.58.1 (version in image is 2.48.2-12.46.1).
-
Description: A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools < 2.48.2-12.58.1 (version in image is 2.48.2-12.46.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:
- zypper > 0-0 (version in image is 1.13.67-21.64.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- gpg2 > 0-0 (version in image is 2.0.24-9.14.1).
-
Description: The display_debug_frames function in dwarf.c in GNU Binutils 2.29.1 allows remote attackers to cause a denial of service (integer overflow and heap-based buffer over-read, and application crash) or possibly have unspecified other impact via a crafted ELF file, related to print_debug_frame.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The print_gnu_property_note function in readelf.c in GNU Binutils 2.29.1 does not have integer-overflow protection on 32-bit platforms, which allows remote attackers to cause a denial of service (segmentation violation and application crash) or possibly have unspecified other impact via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()There is an use-after-free reported by KASAN: BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82 Read of size 1 at addr ffff888112afc460 by task modprobe/2111 CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), Call Trace: kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5 acpi_ds_store_object_to_local+0x15d/0x3a0 acpi_ex_store+0x78d/0x7fd acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b acpi_ps_parse_aml+0x217/0x8d5 ... The root cause of the problem is that the acpi_operand_objectis freed when acpi_ut_walk_package_tree() fails inacpi_ut_copy_ipackage_to_ipackage(), lead to repeated release inacpi_ut_copy_iobject_to_iobject(). The problem was introducedby "8aa5e56eeb61" commit, this commit is to fix memory leak inacpi_ut_copy_iobject_to_iobject(), repeatedly adding removeoperation, lead to "acpi_operand_object" used after free.Fix it by removing acpi_ut_remove_reference() inacpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()is called to copy an internal package object into another internalpackage object, when it fails, the memory of acpi_operand_objectshould be freed by the caller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Delay the unmapping of the bufferOn WCN3990, we are seeing a rare scenario where copy engine hardware issending a copy complete interrupt to the host driver while stillprocessing the buffer that the driver has sent, this is leading into anSMMU fault triggering kernel panic. This is happening on copy enginechannel 3 (CE3) where the driver normally enqueues WMI commands to thefirmware. Upon receiving a copy complete interrupt, host driver willimmediately unmap and frees the buffer presuming that hardware hasprocessed the buffer. In the issue case, upon receiving copy completeinterrupt, host driver will unmap and free the buffer but since hardwareis still accessing the buffer (which in this case got unmapped inparallel), SMMU hardware will trigger an SMMU fault resulting in akernel panic.In order to avoid this, as a work around, add a delay before unmappingthe copy engine source DMA buffer. This is conditionally done forWCN3990 and only for the CE3 channel where issue is seen.Below is the crash signature:wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandledcontext fault: fsr=0x402, iova=0x7fdfd8ac0,fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandledcontext fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal errorreceived: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149remoteproc remoteproc0: crash detected in4080000.remoteproc: type fatal error <3> remoteproc remoteproc0:handling crash #1 in 4080000.remoteprocpc : __arm_lpae_unmap+0x500/0x514lr : __arm_lpae_unmap+0x4bc/0x514sp : ffffffc011ffb530x29: ffffffc011ffb590 x28: 0000000000000000x27: 0000000000000000 x26: 0000000000000004x25: 0000000000000003 x24: ffffffc011ffb890x23: ffffffa762ef9be0 x22: ffffffa77244ef00x21: 0000000000000009 x20: 00000007fff7c000x19: 0000000000000003 x18: 0000000000000000x17: 0000000000000004 x16: ffffffd7a357d9f0x15: 0000000000000000 x14: 00fd5d4fa7ffffffx13: 000000000000000e x12: 0000000000000000x11: 00000000ffffffff x10: 00000000fffffe00x9 : 000000000000017c x8 : 000000000000000cx7 : 0000000000000000 x6 : ffffffa762ef9000x5 : 0000000000000003 x4 : 0000000000000004x3 : 0000000000001000 x2 : 00000007fff7c000x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:__arm_lpae_unmap+0x500/0x514__arm_lpae_unmap+0x4bc/0x514__arm_lpae_unmap+0x4bc/0x514arm_lpae_unmap_pages+0x78/0xa4arm_smmu_unmap_pages+0x78/0x104__iommu_unmap+0xc8/0x1e4iommu_unmap_fast+0x38/0x48__iommu_dma_unmap+0x84/0x104iommu_dma_free+0x34/0x50dma_free_attrs+0xa4/0xd0ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c[ath10k_core]ath10k_halt+0x11c/0x180 [ath10k_core]ath10k_stop+0x54/0x94 [ath10k_core]drv_stop+0x48/0x1c8 [mac80211]ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c[mac80211]__dev_open+0xb4/0x174__dev_change_flags+0xc4/0x1dcdev_change_flags+0x3c/0x7cdevinet_ioctl+0x2b4/0x580inet_ioctl+0xb0/0x1b4sock_do_ioctl+0x4c/0x16ccompat_ifreq_ioctl+0x1cc/0x35ccompat_sock_ioctl+0x110/0x2ac__arm64_compat_sys_ioctl+0xf4/0x3e0el0_svc_common+0xb4/0x17cel0_svc_compat_handler+0x2c/0x58el0_svc_compat+0x8/0x2cTested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()The function lio_target_nacl_info_show() uses sprintf() in a loop to printdetails for every iSCSI connection in a session without checking for thebuffer length. With enough iSCSI connections it's possible to overflow thebuffer provided by configfs and corrupt the memory.This patch replaces sprintf() with sysfs_emit_at() that checks for bufferboundries.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: raid1: fix potential OOB in raid1_remove_disk()If rddev->raid_disk is greater than mddev->raid_disks, there will bean out-of-bounds in raid1_remove_disk(). We have already foundsimilar reports as follows:1) commit d17f744e883b ("md-raid10: fix KASAN warning")2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")Fix this bug by checking whether the "number" variable isvalid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- runc < 1.3.3-16.70.1 (version in image is 1.2.6-16.60.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().smc_clc_prfx_set() is called during connect() and not under RCUnor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()after kernel_getsockname().Note that the returned value of smc_clc_prfx_set() is not usedin the caller.While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()not to touch dst there.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- tar > 0-0 (version in image is 1.27.1-15.24.1).
-
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- runc < 1.3.3-16.70.1 (version in image is 1.2.6-16.60.2).
-
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- runc < 1.3.3-16.70.1 (version in image is 1.2.6-16.60.2).
-
Description: getchar.c in Vim before 8.1.1365 and Neovim before 0.3.6 allows remote attackers to execute arbitrary OS commands via the :source! command in a modeline, as demonstrated by execute in Vim, and assert_fails or nvim_input in Neovim.
Packages affected:
- vim-data-common > 0-0 (version in image is 9.1.1629-17.51.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools < 2.48.2-12.52.1 (version in image is 2.48.2-12.46.1).
-
Description: dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, miscalculates DW_FORM_ref_addr die refs in the case of a relocatable object file, which allows remote attackers to cause a denial of service (find_abstract_instance_name invalid memory read, segmentation fault, and application crash).
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- openssl > 0-0 (version in image is 1.0.2p-1.13).
-
Description: OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Starting in version 0.37.0 and prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels `net.peer.sock.addr` and `net.peer.sock.port` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passing `otelgrpc.WithMeterProvider` option with `noop.NewMeterProvider`.
Packages affected:
- sle-module-containers-release >= 12-0 (version in image is 12-6.9.1).
- docker > 0-0 (version in image is 28.4.0_ce-98.143.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix session state check in reconnect to avoid use-after-free issueDon't collect exiting session in smb2_reconnect_server(), because itwill be released soon.Note that the exiting session will stay in server->smb_ses_list untilit complete the cifs_free_ipc() and logoff() and then delete itselffrom the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- bind-utils > 0-0 (version in image is 9.11.22-3.60.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxslt1 < 1.1.28-17.21.1 (version in image is 1.1.28-17.18.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).
- amazon-ssm-agent > 0-0 (version in image is 3.3.1611.0-4.39.1).
-
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- containerd > 0-0 (version in image is 1.7.27-16.100.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- amazon-ssm-agent < 3.3.1611.0-4.42.1 (version in image is 3.3.1611.0-4.39.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix ipv4 null-ptr-deref in route error pathThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()without ensuring skb->dev is set, leading to a NULL pointer dereferencein fib_compute_spec_dst() when ipv4_link_failure() attempts to sendICMP destination unreachable messages.The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip optionsin ipv4_link_failure") started calling __ip_options_compile() fromipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()which dereferences skb->dev. An attempt was made to fix the NULL skb->devdereference in commit 0113d9c9d1cc ("ipv4: fix null-deref inipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)dereference by using a fallback device. The fix was incomplete becausefib_compute_spec_dst() later in the call chain still accesses skb->devdirectly, which remains NULL when IPVS calls dst_link_failure().The crash occurs when:1. IPVS processes a packet in NAT mode with a misconfigured destination2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route3. The error path calls dst_link_failure(skb) with skb->dev == NULL4. ipv4_link_failure() -> ipv4_send_dest_unreach() -> __ip_options_compile() -> fib_compute_spec_dst()5. fib_compute_spec_dst() dereferences NULL skb->devApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fixipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev beforecalling dst_link_failure().KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285Call Trace: spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()There exists a kernel oops caused by a BUG_ON(nhead < 0) atnet/core/skbuff.c:2232 in pskb_expand_head().This bug is triggered as part of the calipso_skbuff_setattr()routine when skb_cow() is passed headroom > INT_MAX(i.e. (int)(skb_headroom(skb) + len_delta) < 0).The root cause of the bug is due to an implicit integer cast in__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensurethat delta = headroom - skb_headroom(skb) is never negative, otherwisewe will trigger a BUG_ON in pskb_expand_head(). However, ifheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, deltabecomes negative, and pskb_expand_head() is passed a negative value fornhead.Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()by only using skb_cow() to grow headroom.PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verfA zero length gss_token results in pages == 0 and in_token->pages[0]is NULL. The code unconditionally evaluatespage_address(in_token->pages[0]) for the initial memcpy, which candereference NULL even when the copy length is 0. Guard the firstmemcpy so it only runs when length > 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.2, a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. This vulnerability is fixed in 0.6.2.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-pyasn1 < 0.1.9-4.11.1 (version in image is 0.1.9-4.6.1).
-
Description: An exploitable denial-of-service vulnerability exists in the X509 certificate parser of Python.org Python 2.7.11 / 3.6.6. A specially crafted X509 certificate can cause a NULL pointer dereference, resulting in a denial of service. An attacker can initiate or accept TLS connections using crafted certificates to trigger this vulnerability.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: Python 2.7.x through 2.7.16 and 3.x through 3.7.2 is affected by: Improper Handling of Unicode Encoding (with an incorrect netloc) during NFKC normalization. The impact is: Information disclosure (credentials, cookies, etc. that are cached against a given hostname). The components are: urllib.parse.urlsplit, urllib.parse.urlparse. The attack vector is: A specially crafted URL could be incorrectly parsed to locate cookies or authentication data and send that information to a different host than when parsed correctly. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.7, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.3, v3.7.3rc1, v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- ntp > 0-0 (version in image is 4.2.8p17-106.7.1).
-
Description: pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python3-PyJWT > 0-0 (version in image is 1.5.3-3.16.1).
-
Description: GNU gdb All versions is affected by: Buffer Overflow - Out of bound memory access. The impact is: Deny of Service, Memory Disclosure, and Possible Code Execution. The component is: The main gdb module. The attack vector is: Open an ELF for debugging. The fixed version is: Not fixed yet.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- containerd < 1.7.29-16.105.1 (version in image is 1.7.27-16.100.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing '\0' character.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools > 0-0 (version in image is 2.48.2-12.46.1).
-
Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools < 2.48.2-12.52.1 (version in image is 2.48.2-12.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktlsWhen sending plaintext data, we initially calculated the correspondingciphertext length. However, if we later reduced the plaintext data lengthvia socket policy, we failed to recalculate the ciphertext length.This results in transmitting buffers containing uninitialized data duringciphertext transmission.This causes uninitialized bytes to be appended after a complete"Application Data" packet, leading to errors on the receiving end whenparsing TLS record.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 < 1.6.8-15.12.1 (version in image is 1.6.8-15.5.2).
-
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:
- sle-module-web-scripting-release >= 12-0 (version in image is 12-10.3.1).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: SQLite before 3.25.3, when the FTS3 extension is enabled, encounters an integer overflow (and resultant buffer overflow) for FTS3 queries that occur after crafted changes to FTS3 shadow tables, allowing remote attackers to execute arbitrary code by leveraging the ability to run arbitrary SQL statements (such as in certain WebSQL use cases), aka Magellan.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- sqlite3-tcl > 0-0 (version in image is 3.50.2-9.41.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: idle: Check acpi_fetch_acpi_dev() return valueThe return value of acpi_fetch_acpi_dev() could be NULL, which wouldcause a NULL pointer dereference to occur in acpi_device_hid().[ rjw: Subject and changelog edits, added empty line after if () ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: fix UAF/GPF bug in nilfs_mdt_destroyIn alloc_inode, inode_init_always() could return -ENOMEM ifsecurity_inode_alloc() fails, which causes inode->i_privateuninitialized. Then nilfs_is_metadata_file_inode() returnstrue and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),which frees the uninitialized inode->i_privateand leads to crashes(e.g., UAF/GPF).Fix this by moving security_inode_alloc just prior tothis_cpu_inc(nr_inodes)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free in ext4_orphan_cleanupI caught a issue as follows:================================================================== BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0 Read of size 8 at addr ffff88814b13f378 by task mount/710 CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370 Call Trace: dump_stack_lvl+0x73/0x9f print_report+0x25d/0x759 kasan_report+0xc0/0x120 __asan_load8+0x99/0x140 __list_add_valid+0x28/0x1a0 ext4_orphan_cleanup+0x564/0x9d0 [ext4] __ext4_fill_super+0x48e2/0x5300 [ext4] ext4_fill_super+0x19f/0x3a0 [ext4] get_tree_bdev+0x27b/0x450 ext4_get_tree+0x19/0x30 [ext4] vfs_get_tree+0x49/0x150 path_mount+0xaae/0x1350 do_mount+0xe2/0x110 __x64_sys_mount+0xf0/0x190 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...]==================================================================Above issue may happen as follows:-------------------------------------ext4_fill_super ext4_orphan_cleanup --- loop1: assume last_orphan is 12 --- list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan) ext4_truncate --> return 0 ext4_inode_attach_jinode --> return -ENOMEM iput(inode) --> free inode<12> --- loop2: last_orphan is still 12 --- list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan); // use inode<12> and trigger UAFTo solve this issue, we need to propagate the return value ofext4_inode_attach_jinode() appropriately.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mrp: introduce active flags to prevent UAF when applicant uninitThe caller of del_timer_sync must prevent restarting of the timer, Ifwe have no this synchronization, there is a small probability that thecancellation will not be successful.And syzbot report the fellowing crash:==================================================================BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605Write at addr f9ff000024df6058 by task syz-fuzzer/2256Pointer tag: [f9], memory tag: [fe]CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-ge01d50cbd6ee #0Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519To fix it, we can introduce a new active flags to make sure the timer willnot restart.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - fix DMA transfer directionWhen CONFIG_DMA_API_DEBUG is selected, while running the crypto selftest on the QAT crypto algorithms, the function add_dma_entry() reportsa warning similar to the one below, saying that overlapping mappingsare not supported. This occurs in tests where the input and the outputscatter list point to the same buffers (i.e. two different scatter listswhich point to the same chunks of memory).The logic that implements the mapping uses the flag DMA_BIDIRECTIONALfor both the input and the output scatter lists which leads tooverlapped write mappings. These are not supported by the DMA layer.Fix by specifying the correct DMA transfer directions when mappingbuffers. For in-place operations where the input scatter listmatches the output scatter list, buffers are mapped once withDMA_BIDIRECTIONAL, otherwise input buffers are mapped using the flagDMA_TO_DEVICE and output buffers are mapped with DMA_FROM_DEVICE.Overlapping a read mapping with a write mapping is a valid case indma-coherent devices like QAT.The function that frees and unmaps the buffers, qat_alg_free_bufl()has been changed accordingly to the changes to the mapping function. DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270 ... Call Trace: dma_map_page_attrs+0x82/0x2d0 ? preempt_count_add+0x6a/0xa0 qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat] crypto_aead_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 ? scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 ? test_aead_vec+0xdf/0x120 test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 ? crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30 cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()Fix a stack-out-of-bounds write that occurs in a WMI response callbackfunction that is called after a timeout occurs in ath9k_wmi_cmd().The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer thatcould no longer be valid when a timeout occurs. Set wmi->last_seq_id to0 when a timeout occurred.Found by a modified version of syzkaller.BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rxWrite of size 4Call Trace: memcpy ath9k_wmi_ctrl_rx ath9k_htc_rx_msg ath9k_hif_usb_reg_in_cb __usb_hcd_giveback_urb usb_hcd_giveback_urb dummy_timer call_timer_fn run_timer_softirq __do_softirq irq_exit_rcu sysvec_apic_timer_interrupt
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in tcp_write_timer_handler().With Eric's ref tracker, syzbot finally found a repro foruse-after-free in tcp_write_timer_handler() by kernel TCPsockets. [0]If SMC creates a kernel socket in __smc_create(), the kernelsocket is supposed to be freed in smc_clcsock_release() bycalling sock_release() when we close() the parent SMC socket.However, at the end of smc_clcsock_release(), the kernelsocket's sk_state might not be TCP_CLOSE. This means thatwe have not called inet_csk_destroy_sock() in __tcp_close()and have not stopped the TCP timers.The kernel socket's TCP timers can be fired later, so weneed to hold a refcnt for net as we do for MPTCP subflowsin mptcp_subflow_create_socket().[0]:leaked reference. sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108) inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244) __sock_create (net/socket.c:1546) smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284) __sock_create (net/socket.c:1546) __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661) __x64_sys_socket (net/socket.c:1672) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)==================================================================BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) kasan_report (mm/kasan/report.c:538) tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022) run_timer_softirq (kernel/time/timer.c:2037) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572) __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650) irq_exit_rcu (kernel/softirq.c:664) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()The ucmd->log_sq_bb_count variable is controlled by the user so thisshift can wrap. Fix it by using check_shl_overflow() in the same waythat it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefinedbehavior in hns_roce_set_user_sq_size()").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add validation for ring_len paramThe `ring_len` parameter provided by the virtual function (VF)is assigned directly to the hardware memory context (HMC) withoutany validation.To address this, introduce an upper boundary check for both Tx and Rxqueue lengths. The maximum number of descriptors supported by thehardware is 8k-32.Additionally, enforce alignment constraints: Tx rings must be a multipleof 8, and Rx rings must be a multiple of 32.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: Defer ip_vs_ftp unregister during netns cleanupOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftpbefore connections with valid cp->app pointers are flushed, leading to ause-after-free.Fix this by introducing a global `exiting_module` flag, set to true inip_vs_ftp_exit() before unregistering the pernet subsystem. In__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netnscleanup (when exiting_module is false) and defer it to__ip_vs_cleanup_batch(), which unregisters all apps after all connectionsare flushed. If called during module exit, unregister ip_vs_ftpimmediately.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().syzbot reported the splat below in tcp_conn_request(). [0]If a listener is close()d while a TFO socket is being processed intcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->skand calls inet_child_forget(), which calls tcp_disconnect() for theTFO socket.After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),where reqsk_put() is called due to !reqsk->sk.Then, reqsk_fastopen_remove() in tcp_conn_request() decrements thelast req->rsk_refcnt and frees reqsk, and __reqsk_free() at thedrop_and_free label causes the refcount underflow for the listenerand double-free of the reqsk.Let's remove reqsk_fastopen_remove() in tcp_conn_request().Note that other callers make sure tp->fastopen_rsk is not NULL.[0]:refcount_t: underflow; use-after-free.WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)Modules linked in:CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0Call Trace: tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_conn_freeBUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410net/bluetooth/sco.c:107Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci13 hci_cmd_sync_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: fsl-usb: Fix use-after-free in delayed work during device removalThe delayed work item otg_event is initialized in fsl_otg_conf() andscheduled under two conditions:1. When a host controller binds to the OTG controller.2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via fsl_otg_remove():the fsl_otg instance may be freed while the delayed work is still pendingor executing. This leads to use-after-free when the work functionfsl_otg_event() accesses the already freed memory.The problematic scenario:(detach thread) | (delayed work)fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove()before deallocating the fsl_otg structure. This ensures the delayed workis properly canceled and completes execution prior to memory deallocation.This bug was identified through static analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add VLAN id validation before usingCurrently, the VLAN id may be used without validation whenreceive a VLAN configuration mailbox from VF. The length ofvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may causeout-of-bounds memory access once the VLAN id is bigger thanor equal to VLAN_N_VID.Therefore, VLAN id needs to be checked to ensure it is withinthe range of VLAN_N_VID.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: do not free existing class in qfq_change_class()Fixes qfq_change_class() error case.cl->qdisc and cl should only be freed if a new class and qdiscwere allocated, or we risk various UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix possible UAF in macvlan_forward_source()Add RCU protection on (struct macvlan_source_entry)->vlan.Whenever macvlan_hash_del_source() is called, we must clearentry->vlan pointer before RCU grace period starts.This allows macvlan_forward_source() to skip overentries queued for freeing.Note that macvlan_dev are already RCU protected, as theyare embedded in a standard netdev (netdev_priv(ndev)).https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: buffer.c in named in ISC BIND 9.10.x before 9.10.3-P3, when debug logging is enabled, allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon exit, or daemon crash) or possibly have unspecified other impact via (1) OPT data or (2) an ECS option.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- bind-utils > 0-0 (version in image is 9.11.22-3.60.2).
-
Description: named in ISC BIND 9.x before 9.9.8-P4 and 9.10.x before 9.10.3-P4 does not properly handle DNAME records when parsing fetch reply messages, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a malformed packet to the rndc (aka control channel) interface, related to alist.c and sexpr.c.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.60.2).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: resolver.c in named in ISC BIND 9.10.x before 9.10.3-P4, when DNS cookies are enabled, allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via a malformed packet with more than one cookie option.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- bind-utils > 0-0 (version in image is 9.11.22-3.60.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: Crypt::Sodium::XS module versions prior to 0.000042, for Perl, include a vulnerable version of libsodiumlibsodium <= 1.0.20 or a version of libsodium released before December 30, 2025 contains a vulnerability documented as CVE-2025-69277 https://www.cve.org/CVERecord?id=CVE-2025-69277 .The libsodium vulnerability states:In atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.0.000042 includes a version of libsodium updated to 1.0.20-stable, released January 3, 2026, which includes a fix for the vulnerability.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- libsodium23 < 1.0.16-1.12.1 (version in image is 1.0.16-1.9.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: storage: sddr55: Reject out-of-bound new_pbaDiscovered by Atuin - Automated Vulnerability Discovery Engine.new_pba comes from the status packet returned after each write.A bogus device could report values beyond the block count derivedfrom info->capacity, letting the driver walk off the end ofpba_to_lba[] and corrupt heap memory.Reject PBAs that exceed the computed block count and fail thetransfer so we avoid touching out-of-range mapping entries.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lwt: Fix return values of BPF xmit opsBPF encap ops can return different types of positive values, such likeNET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from functionskb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such returnvalues would be treated implicitly as LWTUNNEL_XMIT_CONTINUE inip(6)_finish_output2. When this happens, skbs that have been freed wouldcontinue to the neighbor subsystem, causing use-after-free bug andkernel crashes.To fix the incorrect behavior, skb_do_redirect return values can besimply discarded, the same as tc-egress behavior. On the other hand,bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTUinformation. Thus convert its return values to avoid the conflict withLWTUNNEL_XMIT_CONTINUE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: Avoid nf_ct_helper_hash uses after freeIf nf_conntrack_init_start() fails (for example due to aregister_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()clean-up path frees the nf_ct_helper_hash map.When built with NF_CONNTRACK=y, further netfilter modules (e.g:netfilter_conntrack_ftp) can still be loaded and callnf_conntrack_helpers_register(), independently of whether nf_conntrackinitialized correctly. This accesses the nf_ct_helper_hash danglingpointer and causes a uaf, possibly leading to random memory corruption.This patch guards nf_conntrack_helper_register() from accessing a freedor uninitialized nf_ct_helper_hash pointer and fixes possibleuses-after-free when loading a conntrack module.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: "" In X.Org X Server 1.20.4, there is a stack-based buffer overflow in the function XQueryKeymap. For example, by sending ct.c_char 1000 times, an attacker can cause a denial of service (application crash) or possibly have unspecified other impact. Note: It is disputed if the X.Org X Server is involved or if there is a stack overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libX11-6 > 0-0 (version in image is 1.6.2-12.36.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:
- 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.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inodeThere are many places that will get unhappy (and crash) when ext4_iget()returns a bad inode. However, if iget the boot loader inode, allows a badinode to be returned, because the inode may not be initialized. Thismechanism can be used to bypass some checks and cause panic. To solve thisproblem, we add a special iget flag EXT4_IGET_BAD. Only with this flagwe'd be returning bad inode from ext4_iget(), otherwise we always returnthe error code if the inode is bad inode.(suggested by Jan Kara)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix OOB Read in __hfs_brec_findSyzbot reported a OOB read bug:==================================================================BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190fs/hfs/string.c:84Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted6.1.0-rc6-syzkaller-00308-g644e9524388a #0Workqueue: writeback wb_workfn (flush-7:0)Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75 hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138 hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462 write_inode fs/fs-writeback.c:1440 [inline]If the input inode of hfs_write_inode() is incorrect:struct inode struct hfs_inode_info struct hfs_cat_key struct hfs_name u8 len # len is greater than HFS_NAMELEN(31) which is themaximum length of an HFS filenameOOB read occurred:hfs_write_inode() hfs_brec_find() __hfs_brec_find() hfs_cat_keycmp() hfs_strcmp() # OOB read occurred due to len is too largeFix this by adding a Check on len in hfs_write_inode() before callinghfs_brec_find().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: Fix use-after-free on ar5523_cmd() timed outsyzkaller reported use-after-free with the stack trace like below [1]:[ 38.960489][ C3] ==================================================================[ 38.963216][ C3] BUG: KASAN: use-after-free in ar5523_cmd_tx_cb+0x220/0x240[ 38.964950][ C3] Read of size 8 at addr ffff888048e03450 by task swapper/3/0[ 38.966363][ C3][ 38.967053][ C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.0.0-09039-ga6afa4199d3d-dirty #18[ 38.968464][ C3] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014[ 38.969959][ C3] Call Trace:[ 38.970841][ C3] [ 38.971663][ C3] dump_stack_lvl+0xfc/0x174[ 38.972620][ C3] print_report.cold+0x2c3/0x752[ 38.973626][ C3] ? ar5523_cmd_tx_cb+0x220/0x240[ 38.974644][ C3] kasan_report+0xb1/0x1d0[ 38.975720][ C3] ? ar5523_cmd_tx_cb+0x220/0x240[ 38.976831][ C3] ar5523_cmd_tx_cb+0x220/0x240[ 38.978412][ C3] __usb_hcd_giveback_urb+0x353/0x5b0[ 38.979755][ C3] usb_hcd_giveback_urb+0x385/0x430[ 38.981266][ C3] dummy_timer+0x140c/0x34e0[ 38.982925][ C3] ? notifier_call_chain+0xb5/0x1e0[ 38.984761][ C3] ? rcu_read_lock_sched_held+0xb/0x60[ 38.986242][ C3] ? lock_release+0x51c/0x790[ 38.987323][ C3] ? _raw_read_unlock_irqrestore+0x37/0x70[ 38.988483][ C3] ? __wake_up_common_lock+0xde/0x130[ 38.989621][ C3] ? reacquire_held_locks+0x4a0/0x4a0[ 38.990777][ C3] ? lock_acquire+0x472/0x550[ 38.991919][ C3] ? rcu_read_lock_sched_held+0xb/0x60[ 38.993138][ C3] ? lock_acquire+0x472/0x550[ 38.994890][ C3] ? dummy_urb_enqueue+0x860/0x860[ 38.996266][ C3] ? do_raw_spin_unlock+0x16f/0x230[ 38.997670][ C3] ? dummy_urb_enqueue+0x860/0x860[ 38.999116][ C3] call_timer_fn+0x1a0/0x6a0[ 39.000668][ C3] ? add_timer_on+0x4a0/0x4a0[ 39.002137][ C3] ? reacquire_held_locks+0x4a0/0x4a0[ 39.003809][ C3] ? __next_timer_interrupt+0x226/0x2a0[ 39.005509][ C3] __run_timers.part.0+0x69a/0xac0[ 39.007025][ C3] ? dummy_urb_enqueue+0x860/0x860[ 39.008716][ C3] ? call_timer_fn+0x6a0/0x6a0[ 39.010254][ C3] ? cpuacct_percpu_seq_show+0x10/0x10[ 39.011795][ C3] ? kvm_sched_clock_read+0x14/0x40[ 39.013277][ C3] ? sched_clock_cpu+0x69/0x2b0[ 39.014724][ C3] run_timer_softirq+0xb6/0x1d0[ 39.016196][ C3] __do_softirq+0x1d2/0x9be[ 39.017616][ C3] __irq_exit_rcu+0xeb/0x190[ 39.019004][ C3] irq_exit_rcu+0x5/0x20[ 39.020361][ C3] sysvec_apic_timer_interrupt+0x8f/0xb0[ 39.021965][ C3] [ 39.023237][ C3] In ar5523_probe(), ar5523_host_available() calls ar5523_cmd() as below(there are other functions which finally call ar5523_cmd()):ar5523_probe()-> ar5523_host_available() -> ar5523_cmd_read() -> ar5523_cmd()If ar5523_cmd() timed out, then ar5523_host_available() failed andar5523_probe() freed the device structure. So, ar5523_cmd_tx_cb()might touch the freed structure.This patch fixes this issue by canceling in-flight tx cmd if submittedurb timed out.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: Fix OOB Write in hfs_asc2macSyzbot reported a OOB Write bug:loop0: detected capacity change from 0 to 64==================================================================BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0fs/hfs/trans.c:133Write of size 1 at addr ffff88801848314e by task syz-executor391/3632Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133 hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28 hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740If in->len is much larger than HFS_NAMELEN(31) which is the maximumlength of an HFS filename, a OOB write could occur in hfs_asc2mac(). Inthat case, when the dst reaches the boundary, the srclen is stillgreater than 0, which causes a OOB write.Fix this by adding a check on dstlen in while() before writing to dstaddress.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: Correct devm device reference for hidinput input_dev nameReference the HID device rather than the input device for the devmallocation of the input_dev name. Referencing the input_dev would lead to ause-after-free when the input_dev was unregistered and subsequently fires auevent that depends on the name. At the point of firing the uevent, thename would be freed by devres management.Use devm_kasprintf to simplify the logic for allocating memory andformatting the input_dev name string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Array index may go out of boundKlocwork reports array 'vha->host_str' of size 16 may use index value(s)16..19. Use snprintf() instead of sprintf().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential race when tree connecting ipcProtect access of TCP_Server_Info::hostname when building the ipc treename as it might get freed in cifsd thread and thus causing anuse-after-free bug in __tree_connect_dfs_target(). Also, while at it,update status of IPC tcon on success and then avoid any extra treeconnects.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtraceA received TKIP key may be up to 32 bytes because it may containMIC rx/tx keys too. These are not used by iwl and copying theseover overflows the iwl_keyinfo.key field.Add a check to not copy more data to iwl_keyinfo.key then will fit.This fixes backtraces like this one: memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16) WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm] Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017 RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm] Call Trace: iwl_set_dynamic_key+0x1f0/0x220 [iwldvm] iwlagn_mac_set_key+0x1e4/0x280 [iwldvm] drv_set_key+0xa4/0x1b0 [mac80211] ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211] ieee80211_key_replace+0x22d/0x8e0 [mac80211]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rxFor the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoiduninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() shouldvalidate pkt_len before accessing the SKB.For example, the obtained SKB may have been badly constructed withpkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdrbut after being processed in ath9k_htc_rx_msg() and passed toath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMIcommand header which should be located inside its data payload.Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninitmemory can be referenced.Tested on Qualcomm Atheros Communications AR9271 802.11n .Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libtasn1 > 0-0 (version in image is 4.9-3.16.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast racehuge_pmd_unshare() drops a reference on a page table that may havepreviously been shared across processes, potentially turning it into anormal page table used in another process in which unrelated VMAs canafterwards be installed.If this happens in the middle of a concurrent gup_fast(), gup_fast() couldend up walking the page tables of another process. While I don't see anyway in which that immediately leads to kernel memory corruption, it isreally weird and unexpected.Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),just like we do in khugepaged when removing page tables for a THPcollapse.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOVBefore disabling SR-IOV via config space accesses to the parent PF,sriov_disable() first removes the PCI devices representing the VFs.Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")such removal operations are serialized against concurrent remove andrescan using the pci_rescan_remove_lock. No such locking was ever addedin sriov_disable() however. In particular when commit 18f9e9d150fc("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI deviceremoval into sriov_del_vfs() there was still no locking around thepci_iov_remove_virtfn() calls.On s390 the lack of serialization in sriov_disable() may cause doubleremove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2.This is because in addition to sriov_disable() removing the VFs, theplatform also generates hot-unplug events for the VFs. This being thereverse operation to the hotplug events generated by sriov_enable() andhandled via pdev->no_vf_scan. And while the event processing takespci_rescan_remove_lock and checks whether the struct pci_dev still exists,the lack of synchronization makes this checking racy.Other races may also be possible of course though given that this lack oflocking persisted so long observable races seem very rare. Even on s390 thelist corruption was only observed with certain devices since the platformevents are only triggered by config accesses after the removal, so as longas the removal finished synchronously they would not race. Either way thelocking is missing so fix this by adding it to the sriov_del_vfs() helper.Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()including for the error case where pci_stop_and_remove_bus_device() iscalled without the PCI rescan-remove lock being held. Even in the non-errorcase, adding new PCI devices and buses should be serialized via the PCIrescan-remove lock. Add the necessary locking.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAFThere is a KASAN: slab-use-after-free read in btusb_disconnect().Calling "usb_driver_release_interface(&btusb_driver, data->intf)" willfree the btusb data associated with the interface. The same data isthen used later in the function, hence the UAF.Fix by moving the accesses to btusb data to before the data is free'd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- net-tools > 0-0 (version in image is 1.60-765.15.1).
-
Description: The CNI portmap plugin allows containers to emulate opening a host port, forwarding that traffic to the container. Versions 1.6.0 through 1.8.0 inadvertently forward all traffic with the same destination port as the host port when the portmap plugin is configured with the nftables backend, thus ignoring the destination IP. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node. Containers that request HostPort forwarding can intercept all traffic destined for that port. This requires that the portmap plugin be explicitly configured to use the nftables backend. This issue is fixed in version 1.9.0. To workaround, configure the portmap plugin to use the iptables backend. It does not have this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- docker > 0-0 (version in image is 28.4.0_ce-98.143.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glibc > 0-0 (version in image is 2.22-114.40.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()Blamed commit did not take care of VLAN encapsulationsas spotted by syzbot [1].Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In SQLite through 3.29.0, whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlite_stat1 sz field, aka a "severe division by zero in the query planner."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- sqlite3-tcl > 0-0 (version in image is 3.50.2-9.41.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failedWhen the ops_init() interface is invoked to initialize the net, butops->init() fails, data is released. However, the ptr pointer innet->gen is invalid. In this case, when nfqnl_nf_hook_drop() is invokedto release the net, invalid address access occurs.The process is as follows:setup_net() ops_init() data = kzalloc(...) ---> alloc "data" net_assign_generic() ---> assign "date" to ptr in net->gen ... ops->init() ---> failed ... kfree(data); ---> ptr in net->gen is invalid ... ops_exit_list() ... nfqnl_nf_hook_drop() *q = nfnl_queue_pernet(net) ---> q is invalidThe following is the Call Trace information:BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280Read of size 8 at addr ffff88810396b240 by task ip/15855Call Trace:dump_stack_lvl+0x8e/0xd1print_report+0x155/0x454kasan_report+0xba/0x1f0nfqnl_nf_hook_drop+0x264/0x280nf_queue_nf_hook_drop+0x8b/0x1b0__nf_unregister_net_hook+0x1ae/0x5a0nf_unregister_net_hooks+0xde/0x130ops_exit_list+0xb0/0x170setup_net+0x7ac/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Allocated by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30__kasan_kmalloc+0xa1/0xb0__kmalloc+0x49/0xb0ops_init+0xe7/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Freed by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30kasan_save_free_info+0x2a/0x40____kasan_slab_free+0x155/0x1b0slab_free_freelist_hook+0x11b/0x220__kmem_cache_free+0xa4/0x360ops_init+0xb9/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.6, tvOS 17, iOS 16.7 and iPadOS 16.7, macOS Monterey 12.7, watchOS 10, iOS 17 and iPadOS 17, macOS Sonoma 14. Processing web content may disclose sensitive information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxslt1 > 0-0 (version in image is 1.1.28-17.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firewire: net: fix use after free in fwnet_finish_incoming_packet()The netif_rx() function frees the skb so we can't dereference it tosave the skb->len.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: do not update mtu if msg_max is too small in mtu negotiationWhen doing link mtu negotiation, a malicious peer may send Activate msgwith a very small mtu, e.g. 4 in Shuang's testing, without checking forthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), thenn->links[bearer_id].mtu is set to 4294967228, which is a overflow of'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4!And with tipc_link_entry.mtu 4294967228, a huge skb was allocated innamed_distribute(), and when purging it in tipc_link_xmit(), a crashwas even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),and not updating mtu if it is too small.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: reject auth/assoc to AP with our addressIf the AP uses our own address as its MLD address or BSSID, thenclearly something's wrong. Reject such connections so we don'ttry and fail later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix out-of-bounds access in ipv6_find_tlv()optlen is fetched without checking whether there is more than one byte to parse.It can lead to out-of-bounds access.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hexApparently the hex passphrase mechanism does not work on newerchips/firmware (e.g. BCM4387). It seems there was a simple way ofpassing it in binary all along, so use that and avoid the hexification.OpenBSD has been doing it like this from the beginning, so this shouldwork on all chips.Also clear the structure before setting the PMK. This was leakinguninitialized stack contents to the device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: The hypervisor contains code to accelerate VGA memory accesses for HVMguests, when the (virtual) VGA is in "standard" mode. Locking involvedthere has an unusual discipline, leaving a lock acquired past thereturn from the function that acquired it. This behavior results in aproblem when emulating an instruction with two memory accesses, both ofwhich touch VGA memory (plus some further constraints which aren'trelevant here). When emulating the 2nd access, the lock that is alreadybeing held would be attempted to be re-acquired, resulting in adeadlock.This deadlock was already found when the code was first introduced, butwas analysed incorrectly and the fix was incomplete. Analysis in lightof the new finding cannot find a way to make the existing lockingdiscipline work.In staging, this logic has all been removed because it was discoveredto be accidentally disabled since Xen 4.7. Therefore, we are fixing thelocking problem by backporting the removal of most of the feature. Notethat even with the feature disabled, the lock would still be acquiredfor any accesses to the VGA MMIO region.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- xen-libs > 0-0 (version in image is 4.12.4_62-3.130.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools < 2.48.2-12.52.1 (version in image is 2.48.2-12.46.1).
-
Description: User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- krb5 > 0-0 (version in image is 1.16.3-46.21.1).
-
Description: When passing through PCI devices, the detach logic in libxl won't removeaccess permissions to any 64bit memory BARs the device might have. As aresult a domain can still have access any 64bit memory BAR when suchdevice is no longer assigned to the domain.For PV domains the permission leak allows the domain itself to map the memoryin the page-tables. For HVM it would require a compromised device model orstubdomain to map the leaked memory into the HVM domain p2m.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- xen-libs > 0-0 (version in image is 4.12.4_62-3.130.1).
-
Description: Ruby WEBrick read_header HTTP Request Smuggling Vulnerability. This vulnerability allows remote attackers to smuggle arbitrary HTTP requests on affected installations of Ruby WEBrick. This issue is exploitable when the product is deployed behind an HTTP proxy that fulfills specific conditions.The specific flaw exists within the read_headers method. The issue results from the inconsistent parsing of terminators of HTTP headers. An attacker can leverage this vulnerability to smuggle arbitrary HTTP requests. Was ZDI-CAN-21876.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.33.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctlyThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have aLS_NLA_TYPE_DGID attribute, it is invalid if it does not.Use the nl parsing logic properly and call nla_parse_deprecated() to fillthe nlattrs array and then directly index that array to get the data forthe DGID. Just fail if it is NULL.Remove the for loop searching for the nla, and squash the validation andparsing into one function.Fixes an uninitialized read from the stack triggered by userspace if itdoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVEquery. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: There is a defect in the CPython "tarfile" module affecting the "TarFile" extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. This vulnerability can be mitigated by including the following patch after importing the "tarfile" module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace overzealous BUG_ON in osdmap_apply_incremental()If the osdmap is (maliciously) corrupted such that the incrementalosdmap epoch is different from what is expected, there is no need toBUG. Instead, just declare the incremental osdmap to be invalid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()in an interesting way [1]Crash happens in list_del_init()/INIT_LIST_HEAD() while writinglist->prev, while the prior write on list->next went well.static inline void INIT_LIST_HEAD(struct list_head *list){ WRITE_ONCE(list->next, list); // This went well WRITE_ONCE(list->prev, list); // Crash, @list has been freed.}Issue here is that rt6_uncached_list_del() did not attempt to lockul->lock, as list_empty(&rt->dst.rt_uncached) returnedtrue because the WRITE_ONCE(list->next, list) happened on the other CPU.We might use list_del_init_careful() and list_empty_careful(),or make sure rt6_uncached_list_del() always grabs the spinlockwhenever rt->dst.rt_uncached_list has been set.A similar fix is neeed for IPv4.[1] BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline] BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline] BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: netns cleanup_netCall Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 INIT_LIST_HEAD include/linux/list.h:46 [inline] list_del_init include/linux/list.h:296 [inline] rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853 addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] netif_close_many+0x29c/0x410 net/core/dev.c:1785 unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248 cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 803: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4953 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270 dst_alloc+0x105/0x170 net/core/dst.c:89 ip6_dst_alloc net/ipv6/route.c:342 [inline] icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333 mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.33.1).
-
Description: In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- expat > 0-0 (version in image is 2.7.1-21.46.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: Fix UAF in destroy()Dm_cache also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in destroy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Use different devices for resource allocation and DT lookupFollowing by the below discussion, there's the potential UAF issuebetween regulator and mfd.https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/From the analysis of YingliangCPU A |CPU Bmt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data()i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register()It's common to use mfd core to create child device for the regulator.In order to do the DT lookup for init data, the child that registeredthe regulator would pass its parent as the parameter. And this causesinit data resource allocated to its parent, not itself. The issue happenwhen parent device is going to release and regulator core is still doingsome operation of init data constraint for the regulator of child device.To fix it, this patch expand 'regulator_register' API to use thedifferent devices for init data allocation and DT lookup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware writeDuring the sysfs firmware write process, a use-after-free read warning islogged from the lpfc_wr_object() routine: BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe driver accessed wr_object pointer data, which was initialized intomailbox payload memory, after the mailbox object was released back to themailbox pool.Fix by moving the mailbox free calls to the end of the routine ensuringthat we don't reference internal mailbox memory after release.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add bounds checking in get_max_inline_xattr_value_size()Normally the extended attributes in the inode body would have beenchecked when the inode is first opened, but if someone is writing tothe block device while the file system is mounted, it's possible forthe inode table to get corrupted. Add bounds checking to avoidreading beyond the end of allocated memory if this happens.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Sync IRQ works before buffer destructionIf something was written to the buffer just before destruction,it may be possible (maybe not in a real system, but it didhappen in ARCH=um with time-travel) to destroy the ringbufferbefore the IRQ work ran, leading this KASAN report (or a crashwithout KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00)Add the appropriate irq_work_sync() so the work finishes beforethe buffers are destroyed.Prior to the commit in the Fixes tag below, there was only asingle global IRQ work, so this issue didn't exist.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: Avoid updating block size under exclusive ownerSyzbot came up with a reproducer where a loop device block size ischanged underneath a mounted filesystem. This causes a mismatch betweenthe block device block size and the block size stored in the superblockcausing confusion in various places such as fs/buffer.c. The particularissue triggered by syzbot was a warning in __getblk_slow() due torequested buffer size not matching block device block size.Fix the problem by getting exclusive hold of the loop device to changeits block size. This fails if somebody (such as filesystem) has alreadyan exclusive ownership of the block device and thus prevents modifyingthe loop device under some exclusive owner which doesn't expect it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix race between quota disable and quota rescan ioctlThere's a race between a task disabling quotas and another running therescan ioctl that can result in a use-after-free of qgroup records fromthe fs_info->qgroup_tree rbtree.This happens as follows:1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().Also at btrfs_qgroup_rescan() don't start the rescan worker if quotaswere already disabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cnic: Fix use-after-free bugs in cnic_delete_taskThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),which does not guarantee that the delayed work item 'delete_task' hasfully completed if it was already running. Additionally, the delayed workitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() onlyblocks and waits for work items that were already queued to theworkqueue prior to its invocation. Any work items submitted afterflush_workqueue() is called are not included in the set of tasks that theflush operation awaits. This means that after the cyclic work items havefinished executing, a delayed work item may still exist in the workqueue.This leads to use-after-free scenarios where the cnic_dev is deallocatedby cnic_free_dev(), while delete_task remains active and attempt todereference cnic_dev in cnic_delete_task().A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //useReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the cyclic delayed work item is properly canceled and that anyongoing execution of the work item completes before the cnic_dev isdeallocated. Furthermore, since cancel_delayed_work_sync() uses__flush_work(work, true) to synchronously wait for any currentlyexecuting instance of the work item to finish, the flush_workqueue()becomes redundant and should be removed.This bug was identified through static analysis. To reproduce the issueand validate the fix, I simulated the cnic PCI device in QEMU andintroduced intentional delays - such as inserting calls to ssleep()within the cnic_delete_task() function - to increase the likelihoodof triggering the bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTSUBSAN complains about array-index-out-of-bounds:[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010[ 1.980718] kernel: Call Trace:[ 1.980721] kernel: [ 1.980723] kernel: show_stack+0x52/0x58[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f[ 1.980734] kernel: dump_stack+0x10/0x12[ 1.980736] kernel: ubsan_epilogue+0x9/0x45[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci][ 1.980748] kernel: ata_qc_issue+0x135/0x240[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580[ 1.980754] kernel: ? vprintk_default+0x1d/0x20[ 1.980759] kernel: ata_exec_internal+0x67/0xa0[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci][ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci][ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci][ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci][ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0[ 1.980813] kernel: scsi_error_handler+0xa1/0x180[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0[ 1.980820] kernel: kthread+0x12a/0x150[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50[ 1.980826] kernel: ret_from_fork+0x22/0x30[ 1.980831] kernel: This happens because sata_pmp_init_links() initialize link->pmp up toSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.I can't find the maximum Enclosure Management ports specified in AHCIspec v1.3.1, but "12.2.1 LED message type" states that "Port MultiplierInformation" can utilize 4 bits, which implies it can support up to 16ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve theissue.BugLink: https://bugs.launchpad.net/bugs/1970074
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: si470x: Fix use-after-free in si470x_int_in_callback()syzbot reported use-after-free in si470x_int_in_callback() [1]. Thisindicates that urb->context, which contains struct si470x_deviceobject, is freed when si470x_int_in_callback() is called.The cause of this issue is that si470x_int_in_callback() is called forfreed urb.si470x_usb_driver_probe() calls si470x_start_usb(), which then callsusb_submit_urb() and si470x_start(). If si470x_start_usb() fails,si470x_usb_driver_probe() doesn't kill urb, but it just frees structsi470x_device object, as depicted below:si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urbThis patch fixes this issue by killing urb when si470x_start_usb()fails and urb is submitted. If si470x_start_usb() fails and urb isnot submitted, i.e. submitting usb fails, it just frees structsi470x_device object.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug_on in __es_tree_search caused by bad boot loader inodeWe got a issue as fllows:================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================================================In the above issue, ioctl invokes the swap_inode_boot_loader function toswap inode<5> and inode<12>. However, inode<5> contain incorrect imode anddisordered extents, and i_nlink is set to 1. The extents check for inode inthe ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO.While links_count is set to 1, the extents are not initialized inswap_inode_boot_loader. After the ioctl command is executed successfully,the extents are swapped to inode<12>, in this case, run the `cat` commandto view inode<12>. And Bug_ON is triggered due to the incorrect extents.When the boot loader inode is not initialized, its imode can be one of thefollowing:1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG.2) the imode is good type but not S_IFREG.3) the imode is S_IFREG.The BUG_ON may be triggered by bypassing the check in cases 1 and 2.Therefore, when the boot loader inode is bad_inode or its imode is notS_IFREG, initialize the inode to avoid triggering the BUG.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Don't disable x2APIC if lockedThe APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC(or x2APIC). X2APIC mode is mostly compatible with legacy APIC, butit disables the memory-mapped APIC interface in favor of one that usesMSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.The MMIO/xAPIC interface has some problems, most notably the APIC LEAK[1]. This bug allows an attacker to use the APIC MMIO interface toextract data from the SGX enclave.Introduce support for a new feature that will allow the BIOS to lockthe APIC in x2APIC mode. If the APIC is locked in x2APIC mode and thekernel tries to disable the APIC or revert to legacy APIC mode a GPfault will occur.Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handlethe new locked mode when the LEGACY_XAPIC_DISABLED bit is set bypreventing the kernel from trying to disable the x2APIC.On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX areenabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. Iflegacy APIC is required, then it SGX and TDX need to be disabled in theBIOS.[1]: https://aepicleak.com/aepicleak.pdf
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/sit: use DEV_STATS_INC() to avoid data-racessyzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_errorconcurrently.This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()is not protected by a spinlock.While original KCSAN report was about tx path, rx path has the same issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Detect system inodes linked into directory hierarchyWhen UDF filesystem is corrupted, hidden system inodes can be linkedinto directory hierarchy which is an avenue for further seriouscorruption of the filesystem and kernel confusion as noticed by syzbotfuzzed images. Refuse to access system inodes linked into directoryhierarchy and vice versa.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflowA static code analysis tool flagged the possibility of buffer overflow whenusing copy_from_user() for a debugfs entry.Currently, it is possible that copy_from_user() copies more bytes than whatwould fit in the mybuf char array. Add a min() restriction check betweensizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protectagainst buffer overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kexec: Fix double-free of elf header bufferAfter b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer"),freeing image->elf_headers in the error path of crash_load_segments()is not needed because kimage_file_post_load_cleanup() will takecare of that later. And not clearing it could result in a double-free.Drop the superfluous vfree() call at the error path ofcrash_load_segments().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: usb: siano: Fix use after free bugs caused by do_submit_urbThere are UAF bugs caused by do_submit_urb(). One of the KASan reportsis shown below:[ 36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890[ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49[ 36.408316][ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8[ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584[ 36.416157] Workqueue: 0x0 (events)[ 36.417654] Call Trace:[ 36.418546] [ 36.419320] dump_stack_lvl+0x96/0xd0[ 36.420522] print_address_description+0x75/0x350[ 36.421992] print_report+0x11b/0x250[ 36.423174] ? _raw_spin_lock_irqsave+0x87/0xd0[ 36.424806] ? __virt_addr_valid+0xcf/0x170[ 36.426069] ? worker_thread+0x4a2/0x890[ 36.427355] kasan_report+0x131/0x160[ 36.428556] ? worker_thread+0x4a2/0x890[ 36.430053] worker_thread+0x4a2/0x890[ 36.431297] ? worker_clr_flags+0x90/0x90[ 36.432479] kthread+0x166/0x190[ 36.433493] ? kthread_blkcg+0x50/0x50[ 36.434669] ret_from_fork+0x22/0x30[ 36.435923] [ 36.436684][ 36.437215] Allocated by task 24:[ 36.438289] kasan_set_track+0x50/0x80[ 36.439436] __kasan_kmalloc+0x89/0xa0[ 36.440566] smsusb_probe+0x374/0xc90[ 36.441920] usb_probe_interface+0x2d1/0x4c0[ 36.443253] really_probe+0x1d5/0x580[ 36.444539] __driver_probe_device+0xe3/0x130[ 36.446085] driver_probe_device+0x49/0x220[ 36.447423] __device_attach_driver+0x19e/0x1b0[ 36.448931] bus_for_each_drv+0xcb/0x110[ 36.450217] __device_attach+0x132/0x1f0[ 36.451470] bus_probe_device+0x59/0xf0[ 36.452563] device_add+0x4ec/0x7b0[ 36.453830] usb_set_configuration+0xc63/0xe10[ 36.455230] usb_generic_driver_probe+0x3b/0x80[ 36.456166] printk: console [ttyGS0] disabled[ 36.456569] usb_probe_device+0x90/0x110[ 36.459523] really_probe+0x1d5/0x580[ 36.461027] __driver_probe_device+0xe3/0x130[ 36.462465] driver_probe_device+0x49/0x220[ 36.463847] __device_attach_driver+0x19e/0x1b0[ 36.465229] bus_for_each_drv+0xcb/0x110[ 36.466466] __device_attach+0x132/0x1f0[ 36.467799] bus_probe_device+0x59/0xf0[ 36.469010] device_add+0x4ec/0x7b0[ 36.470125] usb_new_device+0x863/0xa00[ 36.471374] hub_event+0x18c7/0x2220[ 36.472746] process_one_work+0x34c/0x5b0[ 36.474041] worker_thread+0x4b7/0x890[ 36.475216] kthread+0x166/0x190[ 36.476267] ret_from_fork+0x22/0x30[ 36.477447][ 36.478160] Freed by task 24:[ 36.479239] kasan_set_track+0x50/0x80[ 36.480512] kasan_save_free_info+0x2b/0x40[ 36.481808] ____kasan_slab_free+0x122/0x1a0[ 36.483173] __kmem_cache_free+0xc4/0x200[ 36.484563] smsusb_term_device+0xcd/0xf0[ 36.485896] smsusb_probe+0xc85/0xc90[ 36.486976] usb_probe_interface+0x2d1/0x4c0[ 36.488303] really_probe+0x1d5/0x580[ 36.489498] __driver_probe_device+0xe3/0x130[ 36.491140] driver_probe_device+0x49/0x220[ 36.492475] __device_attach_driver+0x19e/0x1b0[ 36.493988] bus_for_each_drv+0xcb/0x110[ 36.495171] __device_attach+0x132/0x1f0[ 36.496617] bus_probe_device+0x59/0xf0[ 36.497875] device_add+0x4ec/0x7b0[ 36.498972] usb_set_configuration+0xc63/0xe10[ 36.500264] usb_generic_driver_probe+0x3b/0x80[ 36.501740] usb_probe_device+0x90/0x110[ 36.503084] really_probe+0x1d5/0x580[ 36.504241] __driver_probe_device+0xe3/0x130[ 36.505548] driver_probe_device+0x49/0x220[ 36.506766] __device_attach_driver+0x19e/0x1b0[ 36.508368] bus_for_each_drv+0xcb/0x110[ 36.509646] __device_attach+0x132/0x1f0[ 36.510911] bus_probe_device+0x59/0xf0[ 36.512103] device_add+0x4ec/0x7b0[ 36.513215] usb_new_device+0x863/0xa00[ 36.514736] hub_event+0x18c7/0x2220[ 36.516130] process_one_work+---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation/dev/vtpmx is made visible before 'workqueue' is initialized, which canlead to a memory corruption in the worst case scenario.Address this by initializing 'workqueue' as the very first step of thedriver initialization.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- curl > 0-0 (version in image is 8.0.1-11.108.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()The hfsplus_bnode_read() method can trigger the issue:[ 174.852007][ T9784] ==================================================================[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784[ 174.854059][ T9784][ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 174.854286][ T9784] Call Trace:[ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0[ 174.854305][ T9784] print_report+0xd0/0x660[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854337][ T9784] kasan_report+0xc6/0x100[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10[ 174.854436][ T9784] ? __asan_memset+0x23/0x50[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10[ 174.854525][ T9784] ? down_write+0x148/0x200[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0[ 174.854549][ T9784] do_unlinkat+0x490/0x670[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10[ 174.854565][ T9784] ? __might_fault+0xbc/0x130[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110[ 174.854592][ T9784] do_syscall_64+0xc9/0x480[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 174.854658][ T9784] [ 174.854661][ T9784][ 174.879281][ T9784] Allocated by task 9784:[ 174.879664][ T9784] kasan_save_stack+0x20/0x40[ 174.880082][ T9784] kasan_save_track+0x14/0x30[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: udf: fix OOB read in lengthAllocDescs handlingWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes fromon-disk data and must be validated against the block size. Crafted orcorrupted images may set lengthAllocDescs so that the total descriptorlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory andtrigger a KASAN use-after-free read.BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make decode_pool() more resilient against corrupted osdmapsIf the osdmap is (maliciously) corrupted such that the encoded lengthof ceph_pg_pool envelope is less than what is expected for a particularencoding version, out-of-bounds reads may ensue because the only boundscheck that is there is based on that length value.This patch adds explicit bounds checks for each field that is decodedor skipped.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib: cpu_rmap: Avoid use after free on rmap->obj array entriesWhen calling irq_set_affinity_notifier() with NULL at the notifyargument, it will cause freeing of the glue pointer in thecorresponding array entry but will leave the pointer in the array. Asubsequent call to free_irq_cpu_rmap() will try to free this entry againleading to possible use after free.Fix that by setting NULL to the array entry and checking that we havenon-zero at the array entry when iterating over the array infree_irq_cpu_rmap().The current code does not suffer from this since there are no caseswhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for thenotify arg) is called, followed by a call to free_irq_cpu_rmap() so wedon't hit and issue. Subsequent patches in this series excersize thisflow, hence the required fix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix an uninit variable access bug in __ip6_make_skb()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because icmp6hdr does not in skb linear region under the scenarioof SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly willtrigger the uninit variable access bug.Use a local variable icmp6_type to carry the correct value in differentscenarios.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: FreeType 2.8.1 has a signed integer overflow in cf2_doFlex in cff/cf2intrp.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libfreetype6 > 0-0 (version in image is 2.6.3-7.24.1).
-
Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- perl > 0-0 (version in image is 5.18.2-12.29.1).
-
Description: Issue summary: Writing large, newline-free data into a BIO chain using theline-buffering filter where the next BIO performs short writes can triggera heap-based out-of-bounds write.Impact summary: This out-of-bounds write can cause memory corruption whichtypically results in a crash, leading to Denial of Service for an application.The line-buffering BIO filter (BIO_f_linebuffer) is not used by default inTLS/SSL data paths. In OpenSSL command-line applications, it is typicallyonly pushed onto stdout/stderr on VMS systems. Third-party applications thatexplicitly use this filter with a BIO chain that can short-write and thatwrite large, newline-free data influenced by an attacker would be affected.However, the circumstances where this could happen are unlikely to be underattacker control, and BIO_f_linebuffer is unlikely to be handling non-curateddata controlled by an attacker. For that reason the issue was assessed asLow severity.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the BIO implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_0_0 < 1.0.2p-3.103.1 (version in image is 1.0.2p-3.98.1).
-
Description: Issue summary: Calling PKCS12_get_friendlyname() function on a maliciouslycrafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containingnon-ASCII BMP code point can trigger a one byte write before the allocatedbuffer.Impact summary: The out-of-bounds write can cause a memory corruptionwhich can have various consequences including a Denial of Service.The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16source byte count as the destination buffer capacity to UTF8_putc(). For BMPcode points above U+07FF, UTF-8 requires three bytes, but the forwardedcapacity can be just two bytes. UTF8_putc() then returns -1, and this negativevalue is added to the output length without validation, causing thelength to become negative. The subsequent trailing NUL byte is then writtenat a negative offset, causing write outside of heap allocated buffer.The vulnerability is reachable via the public PKCS12_get_friendlyname() APIwhen parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses adifferent code path that avoids this issue, PKCS12_get_friendlyname() directlyinvokes the vulnerable function. Exploitation requires an attacker to providea malicious PKCS#12 file to be parsed by the application and the attackercan just trigger a one zero byte write before the allocated buffer.For that reason the issue was assessed as Low severity according to ourSecurity Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_1 < 1.1.1d-2.122.1 (version in image is 1.1.1d-2.119.1).
-
Description: Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointerdereference in the PKCS12_item_decrypt_d2i_ex() function.Impact summary: A NULL pointer dereference can trigger a crash which leads toDenial of Service for an application processing PKCS#12 files.The PKCS12_item_decrypt_d2i_ex() function does not check whether the octparameter is NULL before dereferencing it. When called fromPKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter canbe NULL, causing a crash. The vulnerability is limited to Denial of Serviceand cannot be escalated to achieve code execution or memory disclosure.Exploiting this issue requires an attacker to provide a malformed PKCS#12 fileto an application that processes it. For that reason the issue was assessed asLow severity according to our Security Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_0_0 < 1.0.2p-3.103.1 (version in image is 1.0.2p-3.98.1).
-
Description: Issue summary: An invalid or NULL pointer dereference can happen inan application processing a malformed PKCS#12 file.Impact summary: An application processing a malformed PKCS#12 file can becaused to dereference an invalid or NULL pointer on memory read, resultingin a Denial of Service.A type confusion vulnerability exists in PKCS#12 parsing code wherean ASN1_TYPE union member is accessed without first validating the type,causing an invalid pointer read.The location is constrained to a 1-byte address space, meaning anyattempted pointer manipulation can only target addresses between 0x00 and 0xFF.This range corresponds to the zero page, which is unmapped on most modernoperating systems and will reliably result in a crash, leading only to aDenial of Service. Exploiting this issue also requires a user or applicationto process a maliciously crafted PKCS#12 file. It is uncommon to acceptuntrusted PKCS#12 files in applications as they are usually used to storeprivate keys which are trusted by definition. For these reasons, the issuewas assessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_1 < 1.1.1d-2.122.1 (version in image is 1.1.1d-2.119.1).
-
Description: In the urllib3 library through 1.24.1 for Python, CRLF injection is possible if the attacker controls the request parameter.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: prevent overflow while calculating wait timeThere is a problem found by code review in tg_with_in_bps_limit() that'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem bycalling mul_u64_u64_div_u64() instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Clear nfc_target before being usedFix a slab-out-of-bounds read that occurs in nla_put() called fromnfc_genl_send_target() when target->sensb_res_len, which is duplicatedfrom an nfc_target in pn533, is too large as the nfc_target is notproperly initialized and retains garbage values. Clear nfc_targets withmemset() before they are used.Found by a modified version of syzkaller.BUG: KASAN: slab-out-of-bounds in nla_putCall Trace: memcpy nla_put nfc_genl_dump_targets genl_lock_dumpit netlink_dump __netlink_dump_start genl_family_rcv_msg_dumpit genl_rcv_msg netlink_rcv_skb genl_rcv netlink_unicast netlink_sendmsg sock_sendmsg ____sys_sendmsg ___sys_sendmsg __sys_sendmsg do_syscall_64
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], forioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() withpkt_len = 0 but ath9k_hif_usb_rx_stream() uses__dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption thatpkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skbwith uninitialized memory and ath9k_htc_rx_msg() is reading fromuninitialized memory.Since bytes accessed by ath9k_htc_rx_msg() is not known untilath9k_htc_rx_msg() is called, it would be difficult to check minimal validpkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line inath9k_hif_usb_rx_stream().We have two choices. One is to workaround by adding __GFP_ZERO so thatath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to letath9k_htc_rx_msg() validate pkt_len before accessing. This patch chosethe latter.Note that I'm not sure threshold condition is correct, for I can't finddetails on possible packet length used by this protocol.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-boundsFix a stack-out-of-bounds read in brcmfmac that occurswhen 'buf' that is not null-terminated is passed as an argument ofstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled witha CLM version string by memcpy() in brcmf_fil_iovar_data_get().Ensure buf is null-terminated.Found by a modified version of syzkaller.[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22[ 33.021554][ T1896] ==================================================================[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896[ 33.023852][ T1896][ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event[ 33.026581][ T1896] Call Trace:[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334[ 33.028037][ T1896] ? strreplace+0xf2/0x110[ 33.028403][ T1896] ? strreplace+0xf2/0x110[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf[ 33.029283][ T1896] ? strreplace+0xf2/0x110[ 33.029666][ T1896] strreplace+0xf2/0x110[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0[ 33.033582][ T1896] brcmf_attach+0x246/0xd40[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50[ 33.034383][ T1896] ? kmemdup+0x30/0x40[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710[ 33.036315][ T1896] really_probe+0x1be/0xa90[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0[ 33.037383][ T1896] driver_probe_device+0x49/0x120[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120[ 33.042330][ T1896] __device_attach+0x207/0x330[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260[ 33.043914][ T1896] device_add+0xa61/0x1ce0[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90[ 33.046931][ T1896] usb_probe_device+0x9c/0x220[ 33.047434][ T1896] really_probe+0x1be/0xa90[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460[ 33.048134][ T1896] driver_probe_device+0x49/0x120[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_fq: fix integer overflow of "credit"if sch_fq is configured with "initial quantum" having values greater thanINT_MAX, the first assignment of "credit" does signed integer overflow toa very negative value.In this situation, the syzkaller script provided by Cristoph triggers theCPU soft-lockup warning even with few sockets. It's not an infinite loop,but "credit" wasn't probably meant to be minus 2Gb for each new flow.Capping "initial quantum" to INT_MAX proved to fix the issue.v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix wrong ct->timeout value(struct nf_conn)->timeout is an interval before the conntrackconfirmed. After confirmed, it becomes a timestamp.It is observed that timeout of an unconfirmed conntrack:- Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice.- Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted.Call Trace: dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsgSeparate the 2 cases in:- Setting `ct->timeout` in __nf_ct_set_timeout().- Getting `ct->timeout` in ctnetlink_dump_timeout().Pablo appends:Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag isset on, otherwise conntrack creation via ctnetlink breaks.Note that the problem described in this patch occurs since theintroduction of the nfnetlink_queue conntrack support, select asufficiently old Fixes: tag for -stable kernel to pick up this fix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cdc_ncm: Deal with too low values of dwNtbOutMaxSizeCurrently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower thanthe calculated "min" value, but greater than zero, the logic setstx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB incdc_ncm_fill_tx_frame() where all the data is handled.For small values of dwNtbOutMaxSize the memory allocated duringalloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due tohow size is aligned at alloc time: size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));Thus we hit the same bug that we tried to squash withcommit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")Low values of dwNtbOutMaxSize do not cause an issue presently because atalloc_skb() time more memory (512b) is allocated than required for theSKB headers alone (320b), leaving some space (512b - 320b = 192b)for CDC data (172b).However, if more elements (for example 3 x u64 = [24b]) were added toone of the SKB header structs, say 'struct skb_shared_info',increasing its original size (320b [320b aligned]) to something larger(344b [384b aligned]), then suddenly the CDC data (172b) no longerfits in the spare SKB data area (512b - 384b = 128b).Consequently the SKB bounds checking semantics fails and panics:skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:------------[ cut here ]------------kernel BUG at net/core/skbuff.c:113!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023Workqueue: mld mld_ifc_workRIP: 0010:skb_panic net/core/skbuff.c:113 [inline]RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118[snip]Call Trace: skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100Deal with too low values of dwNtbOutMaxSize, clamp it in the range[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensureenough data space is allocated to handle CDC data by making suredwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/net_failover: fix txq exceeding warningThe failover txq is inited as 16 queues.when a packet is transmitted from the failover device firstly,the failover device will select the queue which is returned fromthe primary device if the primary device is UP and running.If the primary device txq is bigger than the default 16,it can lead to the following warning:eth0 selects TX queue 18, but real number of TX queues is 16The warning backtrace is:[ 32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G E 6.2.8-1.el7.centos.x86_64 #1[ 32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014[ 32.147730] Call Trace:[ 32.147971] [ 32.148183] dump_stack_lvl+0x48/0x70[ 32.148514] dump_stack+0x10/0x20[ 32.148820] netdev_core_pick_tx+0xb1/0xe0[ 32.149180] __dev_queue_xmit+0x529/0xcf0[ 32.149533] ? __check_object_size.part.0+0x21c/0x2c0[ 32.149967] ip_finish_output2+0x278/0x560[ 32.150327] __ip_finish_output+0x1fe/0x2f0[ 32.150690] ip_finish_output+0x2a/0xd0[ 32.151032] ip_output+0x7a/0x110[ 32.151337] ? __pfx_ip_finish_output+0x10/0x10[ 32.151733] ip_local_out+0x5e/0x70[ 32.152054] ip_send_skb+0x19/0x50[ 32.152366] udp_send_skb.isra.0+0x163/0x3a0[ 32.152736] udp_sendmsg+0xba8/0xec0[ 32.153060] ? __folio_memcg_unlock+0x25/0x60[ 32.153445] ? __pfx_ip_generic_getfrag+0x10/0x10[ 32.153854] ? sock_has_perm+0x85/0xa0[ 32.154190] inet_sendmsg+0x6d/0x80[ 32.154508] ? inet_sendmsg+0x6d/0x80[ 32.154838] sock_sendmsg+0x62/0x70[ 32.155152] ____sys_sendmsg+0x134/0x290[ 32.155499] ___sys_sendmsg+0x81/0xc0[ 32.155828] ? _get_random_bytes.part.0+0x79/0x1a0[ 32.156240] ? ip4_datagram_release_cb+0x5f/0x1e0[ 32.156649] ? get_random_u16+0x69/0xf0[ 32.156989] ? __fget_light+0xcf/0x110[ 32.157326] __sys_sendmmsg+0xc4/0x210[ 32.157657] ? __sys_connect+0xb7/0xe0[ 32.157995] ? __audit_syscall_entry+0xce/0x140[ 32.158388] ? syscall_trace_enter.isra.0+0x12c/0x1a0[ 32.158820] __x64_sys_sendmmsg+0x24/0x30[ 32.159171] do_syscall_64+0x38/0x90[ 32.159493] entry_SYSCALL_64_after_hwframe+0x72/0xdcFix that by reducing txq number as the non-existent primary-dev does.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ebtables: fix table blob use-after-freeWe are not allowed to return an error at this point.Looking at the code it looks like ret is always 0 at thispoint, but its not.t = find_table_lock(net, repl->name, &ret, &ebt_mutex);... this can return a valid table, with ret != 0.This bug causes update of table->private with the newblob, but then frees the blob right away in the caller.Syzbot report:BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74Workqueue: netns cleanup_netCall Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613...ip(6)tables appears to be ok (ret should be 0 at this point) but makethis more obvious.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm flakey: don't corrupt the zero pageWhen we need to zero some range on a block device, the function__blkdev_issue_zero_pages submits a write bio with the bio vector pointingto the zero page. If we use dm-flakey with corrupt bio writes option, itwill corrupt the content of the zero page which results in crashes ofvarious userspace programs. Glibc assumes that memory returned by mmap iszeroed and it uses it for calloc implementation; if the newly mappedmemory is not zeroed, calloc will return non-zeroed memory.Fix this bug by testing if the page is equal to ZERO_PAGE(0) andavoiding the corruption in this case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- 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.275.1).
-
Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libblkid1 > 0-0 (version in image is 2.33.2-4.45.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in i40e_validate_queue_mapEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_validate_queue_map().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattrCurrently when both IMA and EVM are in fix mode, the IMA signature willbe reset to IMA hash if a program first stores IMA signature insecurity.ima and then writes/removes some other security xattr for thefile.For example, on Fedora, after booting the kernel with "ima_appraise=fixevm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,installing/reinstalling a package will not make good reference IMAsignature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404...This happens because when setting security.selinux, the IMA_DIGSIG flagthat had been set early was cleared. As a result, IMA hash is generatedwhen the file is closed.Similarly, IMA signature can be cleared on file close after removingsecurity xattr like security.evm or setting/removing ACL.Prevent replacing the IMA file signature with a file hash, by preventingthe IMA_DIGSIG flag from being reset.Here's a minimal C reproducer which sets security.selinux as the laststep which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:via_wdt: fix critical boot hang due to unnamed resource allocationThe VIA watchdog driver uses allocate_resource() to reserve a MMIOregion for the watchdog control register. However, the allocatedresource was not given a name, which causes the kernel resource treeto contain an entry marked as "" under /proc/iomem on x86platforms.During boot, this unnamed resource can lead to a critical hang becausesubsequent resource lookups and conflict checks fail to handle theinvalid entry properly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.1).
-
Description: For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- screen > 0-0 (version in image is 4.0.4-23.9.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- cups-libs > 0-0 (version in image is 1.7.5-20.54.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-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: It was found that the GnuTLS implementation of HMAC-SHA-384 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets.
Packages affected:
- libgnutls30 > 0-0 (version in image is 3.4.17-8.20.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Update ipcomp_scratches with NULL when freedCurrently if ipcomp_alloc_scratches() fails to allocate memoryipcomp_scratches holds obsolete address. So when we try to free thepercpu scratches using ipcomp_free_scratches() it tries to vfree nonexistent vm area. Described below:static void * __percpu *ipcomp_alloc_scratches(void){ ... scratches = alloc_percpu(void *); if (!scratches) return NULL;ipcomp_scratches does not know about this allocation failure.Therefore holding the old obsolete address. ...}So when we free,static void ipcomp_free_scratches(void){ ... scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));Trying to free non existent page, causing warning: trying to vfreeexistent vm area. ...}Fix this breakage by updating ipcomp_scrtches with NULL when scratchesis freed
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_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:
- expat > 0-0 (version in image is 2.7.1-21.46.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- krb5 > 0-0 (version in image is 1.16.3-46.21.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a client that connects to cupsd but sends slow messages, e.g. only one byte per second, delays cupsd as a whole, such that it becomes unusable by other clients. This issue has been patched in version 2.4.15.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- cups-libs > 0-0 (version in image is 1.7.5-20.54.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- gpg2 > 0-0 (version in image is 2.0.24-9.14.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix UBSAN shift-out-of-bounds warningIf get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end updoing a shift operation where the number of bits shifted equalsnumber of bits in the operand. This behaviour is undefined.Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if thecount is >= number of bits in the operand.Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix UAF in run_timer_softirq()When dm_resume() and dm_destroy() are concurrent, it willlead to UAF, as follows: BUG: KASAN: use-after-free in __run_timers+0x173/0x710 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 Call Trace: dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+0x16e/0x62c __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0One of the concurrency UAF can be shown as below: use freedo_resume | __find_device_hash_cell | dm_get | atomic_inc(&md->holders) | | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | atomic_read(&md->holders) | msleep(1) dm_resume | __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add delay work | dm_put | atomic_dec(&md->holders) | | dm_table_destroy | pool_dtr | __pool_dec | __pool_destroy | destroy_workqueue | kfree(pool) # free pool time out__do_softirq run_timer_softirq # pool has already been freedThis can be easily reproduced using: 1. create thin-pool 2. dmsetup suspend pool 3. dmsetup resume pool 4. dmsetup remove_all # Concurrent with 3The root cause of this UAF bug is that dm_resume() adds timer afterdm_destroy() skips cancelling the timer because of suspend status.After timeout, it will call run_timer_softirq(), however pool hasalready been freed. The concurrency UAF bug will happen.Therefore, cancelling timer again in __pool_destroy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix race condition in hidp_session_threadThere is a potential race condition in hidp_session_thread that maylead to use-after-free. For instance, the timer is active whilehidp_del_timer is called in hidp_session_thread(). After hidp_session_put,then 'session' will be freed, causing kernel panic when hidp_idle_timeoutis running.The solution is to use del_timer_sync instead of del_timer.Here is the call trace:? hidp_session_probe+0x780/0x780call_timer_fn+0x2d/0x1e0__run_timers.part.0+0x569/0x940hidp_session_probe+0x780/0x780call_timer_fn+0x1e0/0x1e0ktime_get+0x5c/0xf0lapic_next_deadline+0x2c/0x40clockevents_program_event+0x205/0x320run_timer_softirq+0xa9/0x1b0__do_softirq+0x1b9/0x641__irq_exit_rcu+0xdc/0x190irq_exit_rcu+0xe/0x20sysvec_apic_timer_interrupt+0xa1/0xc0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: uclogic: Correct devm device reference for hidinput input_dev nameReference the HID device rather than the input device for the devmallocation of the input_dev name. Referencing the input_dev would lead to ause-after-free when the input_dev was unregistered and subsequently fires auevent that depends on the name. At the point of firing the uevent, thename would be freed by devres management.Use devm_kasprintf to simplify the logic for allocating memory andformatting the input_dev name string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix potential user-after-freeThis fixes all instances of which requires to allocate a buffer callingalloc_skb which may release the chan lock and reacquire later whichmakes it possible that the chan is disconnected in the meantime.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Address KCSAN report on bpf_lru_listKCSAN reported a data-race when accessing node->ref.Although node->ref does not have to be accurate,take this chance to use a more common READ_ONCE() and WRITE_ONCE()pattern instead of data_race().There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().This patch also adds bpf_lru_node_clear_ref() to do theWRITE_ONCE(node->ref, 0) also.==================================================================BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elemwrite to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023==================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A side channel vulnerability on some of the AMD CPUs may allow an attacker to influence the return address prediction. This may result in speculative execution at an attacker-controlled address, potentially leading to information disclosure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.90.1).
-
Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix off-by-one issues in iavf_config_rss_reg()There are off-by-one bugs when configuring RSS hash key and lookuptable, causing out-of-bounds reads to memory [1] and out-of-boundswrites to device registers.Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4where `rss_{key,lut}_size / 4` is the number of dwords, so the lastvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`accesses one element past the end.Fix the issues by using `<` instead of `<=`, ensuring we do not exceedthe bounds.[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63 CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, mishandles NULL files in a .debug_line file table, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ELF file, related to concat_filename. NOTE: this issue is caused by an incomplete fix for CVE-2017-15023.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The elf_parse_notes function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (out-of-bounds read and segmentation violation) via a note with a large alignment.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.
Packages affected:
- sle-module-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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_fwd_use_pmtu.While reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: When HCI work queue is drained, only queue chained workThe HCI command, event, and data packet processing workqueue is drainedto avoid deadlock in commit76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").There is another delayed work, which will queue command to this drainedworkqueue. Which results in the following error report:Bluetooth: hci2: command 0x040f tx timeoutWARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140Workqueue: events hci_cmd_timeoutRIP: 0010:__queue_work+0xdad/0x1140RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue thetimeout workqueue while command workqueue is draining.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix crash on isr after kexec()If the system is rebooted via isr(), the IRQ handler mightbe triggered before the domain is initialized. Resulting onan invalid memory access error.Fix:[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070[ 0.501166] Call trace:[ 0.501174] report_iommu_fault+0x28/0xfc[ 0.501180] mtk_iommu_isr+0x10c/0x1c0[ joro: Fixed spelling in commit message ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: of: Fix refcount leak bug in of_get_ddr_timings()We should add the of_node_put() when breaking out offor_each_child_of_node() as it will automatically increaseand decrease the refcount.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pnode: terminate at peers of sourceThe propagate_mnt() function handles mount propagation when creatingmounts and propagates the source mount tree @source_mnt to allapplicable nodes of the destination propagation mount tree headed by@dest_mnt.Unfortunately it contains a bug where it fails to terminate at peers of@source_mnt when looking up copies of the source mount that becomemasters for copies of the source mount tree mounted on top of slaves inthe destination propagation tree causing a NULL dereference.Once the mechanics of the bug are understood it's easy to trigger.Because of unprivileged user namespaces it is available to unprivilegedusers.While fixing this bug we've gotten confused multiple times due tounclear terminology or missing concepts. So let's start this with someclarifications:* The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group.* A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share.* The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list.* The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group.* Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked.* Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from.* A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups.* A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group.* A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group pr---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a rangeIf we get -ENOMEM while dropping file extent items in a given range, atbtrfs_drop_extents(), due to failure to allocate memory when attempting toincrement the reference count for an extent or drop the reference count,we handle it with a BUG_ON(). This is excessive, instead we can simplyabort the transaction and return the error to the caller. In fact mostcallers of btrfs_drop_extents(), directly or indirectly, already abortthe transaction if btrfs_drop_extents() returns any error.Also, we already have error paths at btrfs_drop_extents() that may return-ENOMEM and in those cases we abort the transaction, like for exampleanything that changes the b+tree may return -ENOMEM due to a failure toallocate a new extent buffer when COWing an existing extent buffer, suchas a call to btrfs_duplicate_item() for example.So replace the BUG_ON() calls with proper logic to abort the transactionand return the error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix double release compute pasidIf kfd_process_device_init_vm returns failure after vm is converted tocompute vm and vm->pasid set to compute pasid, KFD will not takepdd->drm_file reference. As a result, drm close file handler maybecalled to release the compute pasid before KFD process destroy worker torelease the same pasid and set vm->pasid to zero, this generates belowWARNING backtrace and NULL pointer access.Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last stepof kfd_process_device_init_vm, to ensure vm pasid is the original pasidif acquiring vm failed or is the compute pasid with pdd->drm_filereference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value, the memorythat allocated in mmc_alloc_host() will be leaked and it will lead a kernelcrash because of deleting not added device in the remove path.So fix this by checking the return value and calling mmc_free_host() in theerror path, besides, led_classdev_unregister() and pm_runtime_disable() alsoneed be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: wmt-sdmmc: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value, the memorythat allocated in mmc_alloc_host() will be leaked and it will lead a kernelcrash because of deleting not added device in the remove path.So fix this by checking the return value and goto error path which will callmmc_free_host(), besides, clk_disable_unprepare() also needs be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: sfb: fix null pointer access issue when sfb_init() failsWhen the default qdisc is sfb, if the qdisc of dev_queue fails to beinited during mqprio_init(), sfb_reset() is invoked to clear resources.In this case, the q->qdisc is NULL, and it will cause gpf issue.The process is as follows:qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->opsThe following is the Call Trace information:general protection fault, probably for non-canonical address0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]RIP: 0010:qdisc_reset+0x2b/0x6f0Call Trace:sfb_reset+0x37/0xd0qdisc_reset+0xed/0x6f0qdisc_destroy+0x82/0x4c0qdisc_put+0x9e/0xb0qdisc_create_dflt+0x2c3/0x4a0mqprio_init+0xa71/0x1760qdisc_create+0x3eb/0x1000tc_modify_qdisc+0x408/0x1720rtnetlink_rcv_msg+0x38e/0xac0netlink_rcv_skb+0x12d/0x3a0netlink_unicast+0x4a2/0x740netlink_sendmsg+0x826/0xcc0sock_sendmsg+0xc5/0x100____sys_sendmsg+0x583/0x690___sys_sendmsg+0xe8/0x160__sys_sendmsg+0xbf/0x160do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f2164122d04
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: mux: reg: check return value after calling platform_get_resource()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.And use devm_platform_get_and_ioremap_resource() to simplify code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dsi: fix memory corruption with too many bridgesAdd the missing sanity check on the bridge counter to avoid corruptingdata beyond the fixed-sized bridge array in case there are ever morethan eight bridges.Patchwork: https://patchwork.freedesktop.org/patch/502668/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: ismt: Fix an out-of-bounds bug in ismt_access()When the driver does not check the data from the user, the variable'data->block[0]' may be very large to cause an out-of-bounds bug.The following log can reveal it:[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20[ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE[ 33.996475] ==================================================================[ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b[ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485[ 33.999450] Call Trace:[ 34.001849] memcpy+0x20/0x60[ 34.002077] ismt_access.cold+0x374/0x214b[ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0[ 34.004007] i2c_smbus_xfer+0x10a/0x390[ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710[ 34.005196] i2cdev_ioctl+0x5ec/0x74cFix this bug by checking the size of 'data->block[0]' first.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:integrity: Fix memory leakage in keyring allocation error pathKey restriction is allocated in integrity_init_keyring(). However, ifkeyring allocation failed, it is not freed, causing memory leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: fix NULL-pointer dereferencesThere are several places where we can crash the kernel by requestinglines, unbinding the GPIO device, then calling any of the system callsrelevant to the GPIO character device's annonymous file descriptors:ioctl(), read(), poll().While I observed it with the GPIO simulator, it will also happen for anyof the GPIO devices that can be hot-unplugged - for instance any HID GPIOexpander (e.g. CP2112).This affects both v1 and v2 uAPI.This fixes it partially by checking if gdev->chip is not NULL but itdoesn't entirely remedy the situation as we still have a race conditionin which another thread can remove the device after the check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()Fix a NULL pointer crash that occurs when we are freeing the socket at thesame time we access it via sysfs.The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops.Above we do a get on the "struct sock", but we needed a get on the "structsocket". Originally, we just held the frwd_lock the entire time but incommit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock whilecalling getpeername()") we switched to refcount based because the networklayer changed and started taking a mutex in that path, so we could nolonger hold the frwd_lock.Instead of trying to maintain multiple refcounts, this just has us use amutex for accessing the socket in the interface code paths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()If device_register() fails in cxl_register_afu|adapter(), the deviceis not added, device_unregister() can not be called in the error path,otherwise it will cause a null-ptr-deref because of removing not addeddevice.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crashWhen CPU 0 is offline and intel_powerclamp is used to injectidle, it generates kernel BUG:BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687caller is debug_smp_processor_id+0x17/0x20CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57Call Trace:dump_stack_lvl+0x49/0x63dump_stack+0x10/0x16check_preemption_disabled+0xdd/0xe0debug_smp_processor_id+0x17/0x20powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]......Here CPU 0 is the control CPU by default and changed to the current CPU,if CPU 0 offlined. This check has to be performed under cpus_read_lock(),hence the above warning.Use get_cpu() instead of smp_processor_id() to avoid this BUG.[ rjw: Subject edits ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for dcoda_iram_allocAs the coda_iram_alloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas: avoid scheduling in rtas_os_term()It's unsafe to use rtas_busy_delay() to handle a busy status fromthe ibm,os-term RTAS function in rtas_os_term():Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000bBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 2, expected: 0CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9Call Trace:[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200Use rtas_busy_delay_time() instead, which signals without side effectswhether to attempt the ibm,os-term RTAS call again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix pci device refcount leak in ppr_notifier()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it before returning from ppr_notifier()to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for kmallocAs the kmalloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/fonts: fix undefined behavior in bit shift for get_default_fontShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20left shift of 1 by 31 places cannot be represented in type 'int' dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix invalid derefence of sb_lvbptrI experience issues when putting a lkbsb on the stack and have sb_lvbptrfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crashwith the following kernel message, the dangled pointer is here0xdeadbeef as example:[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef[ 102.749320] #PF: supervisor read access in kernel mode[ 102.749323] #PF: error_code(0x0000) - not-present page[ 102.749325] PGD 0 P4D 0[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 102.749379] PKRU: 55555554[ 102.749381] Call Trace:[ 102.749382] [ 102.749383] ? send_args+0xb2/0xd0[ 102.749389] send_common+0xb7/0xd0[ 102.749395] _unlock_lock+0x2c/0x90[ 102.749400] unlock_lock.isra.56+0x62/0xa0[ 102.749405] dlm_unlock+0x21e/0x330[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture][ 102.749419] ? preempt_count_sub+0xba/0x100[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture][ 102.786186] kthread+0x10a/0x130[ 102.786581] ? kthread_complete_and_exit+0x20/0x20[ 102.787156] ret_from_fork+0x22/0x30[ 102.787588] [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw[ 102.792536] CR2: 00000000deadbeef[ 102.792930] ---[ end trace 0000000000000000 ]---This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflagsis set when copying the lvbptr array instead of if it's just null whichfixes for me the issue.I think this patch can fix other dlm users as well, depending how theyhandle the init, freeing memory handling of sb_lvbptr and don't setDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be ahidden issue all the time. However with checking on DLM_LKF_VALBLK theuser always need to provide a sb_lvbptr non-null value. There might bemore intelligent handling between per ls lvblen, DLM_LKF_VALBLK andnon-null to report the user the way how DLM API is used is wrong but canbe added for later, this will only fix the current behaviour.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix size validation for non-exclusive domains (v4)Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for therequested memory exists, else we get a kernel oops when dereferencing "man".v2: Make the patch standalone, i.e. not dependent on local patches.v3: Preserve old behaviour and just check that the manager pointer is not NULL.v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,sas_rphy_free() needs be called to free the resource allocated insas_end_device_alloc(). Otherwise a kernel crash will happen:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : device_del+0x54/0x3d0lr : device_del+0x37c/0x3d0Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas]Because transport_add_device() is not called when sas_rphy_add() fails, thedevice is not added. When sas_rphy_remove() is subsequently called toremove the device in the remove() path, a NULL pointer dereference happens.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Use last transaction's pmd->root when commit failedRecently we found a softlock up problem in dm thin pool btree lookupcode due to corrupted metadata: Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x9c/0xd3 panic+0x35d/0x6b9 watchdog_timer_fn.cold+0x16/0x25 __run_hrtimer+0xa2/0x2d0 RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio] __bufio_new+0x11f/0x4f0 [dm_bufio] new_read+0xa3/0x1e0 [dm_bufio] dm_bm_read_lock+0x33/0xd0 [dm_persistent_data] ro_step+0x63/0x100 [dm_persistent_data] btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data] dm_btree_lookup+0x16f/0x210 [dm_persistent_data] dm_thin_find_block+0x12c/0x210 [dm_thin_pool] __process_bio_read_only+0xc5/0x400 [dm_thin_pool] process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool] process_one_work+0x3c5/0x730Following process may generate a broken btree mixed with fresh andstale btree nodes, which could get dm thin trapped in an infinite loopwhile looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. process_bio_read_only dm_thin_find_block __find_block dm_btree_lookup(pmd->root)The pmd->root points to a broken btree, Y may contain stale nodepointing to any block, for example X, which gets dm thin trapped intoa dead loop while looking up Z.Fix this by setting pmd->root in __open_metadata(), so that dm thinwill use the last transaction's pmd->root if commit failed.Fetch a reproducer in [Link].Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix repeated calls to sock_put() when msg has more_dataIn tcp_bpf_send_verdict() redirection, the eval variable is assigned to__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,sock_put() will be called multiple times.We should reset the eval variable to __SK_NONE every time more_datastarts.This causes:IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110Modules linked in:CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014Call Trace: __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' willnot be freed through rpi_firmware_delete(), fix this leak by callingkfree() in the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()xhci_alloc_stream_info() allocates stream context array for stream_info->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,stream_info->stream_ctx_array is not released, which will lead to amemory leak.We can fix it by releasing the stream_info->stream_ctx_array withxhci_free_stream_ctx() on the error path to avoid the potential memoryleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:r6040: Fix kmemleak in probe and removeThere is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ...The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problemThe root cause is traced to the phy_device is not disconnected whenremoves one r6040 device in r6040_remove_one() or on error handling pathafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernetdevice is connected to the first PHY device of mii_bus, in order tonotify the connected driver when the link status changes, which is thedefault behavior of the PHY infrastructure to handle everything.Therefore the phy_device should be disconnected when removes one r6040device or on error handling path.Fix it by adding phy_disconnect() when removes one r6040 device or onerror handling path after r6040_mii probed successfully.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadataFollowing concurrent processes: P1(drop cache) P2(kworker)drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block v down_read(&pmd->root_lock) --> ABBA deadlock, which triggers hung task:[ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.[ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2[ 76.978534] Workqueue: dm-thin do_worker[ 76.978552] Call Trace:[ 76.978564] __schedule+0x6ba/0x10f0[ 76.978582] schedule+0x9d/0x1e0[ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0[ 76.978600] down_write+0xec/0x110[ 76.978607] unregister_shrinker+0x2c/0xf0[ 76.978616] dm_bufio_client_destroy+0x116/0x3d0[ 76.978625] dm_block_manager_destroy+0x19/0x40[ 76.978629] __destroy_persistent_data_objects+0x5e/0x70[ 76.978636] dm_pool_abort_metadata+0x8e/0x100[ 76.978643] metadata_operation_failed+0x86/0x110[ 76.978649] commit+0x6a/0x230[ 76.978655] do_worker+0xc6e/0xd90[ 76.978702] process_one_work+0x269/0x630[ 76.978714] worker_thread+0x266/0x630[ 76.978730] kthread+0x151/0x1b0[ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.[ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459[ 76.982128] Call Trace:[ 76.982139] __schedule+0x6ba/0x10f0[ 76.982155] schedule+0x9d/0x1e0[ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910[ 76.982173] down_read+0x84/0x170[ 76.982177] dm_thin_find_block+0x4c/0xd0[ 76.982183] thin_map+0x201/0x3d0[ 76.982188] __map_bio+0x5b/0x350[ 76.982195] dm_submit_bio+0x2b6/0x930[ 76.982202] __submit_bio+0x123/0x2d0[ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0[ 76.982222] submit_bio_noacct+0x389/0x770[ 76.982227] submit_bio+0x50/0xc0[ 76.982232] submit_bh_wbc+0x15e/0x230[ 76.982238] submit_bh+0x14/0x20[ 76.982241] ext4_read_bh_nowait+0xc5/0x130[ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60[ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0[ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0[ 76.982263] ext4_discard_preallocations+0x45d/0x830[ 76.982274] ext4_clear_inode+0x48/0xf0[ 76.982280] ext4_evict_inode+0xcf/0xc70[ 76.982285] evict+0x119/0x2b0[ 76.982290] dispose_list+0x43/0xa0[ 76.982294] prune_icache_sb+0x64/0x90[ 76.982298] super_cache_scan+0x155/0x210[ 76.982303] do_shrink_slab+0x19e/0x4e0[ 76.982310] shrink_slab+0x2bd/0x450[ 76.982317] drop_slab+0xcc/0x1a0[ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0[ 76.982327] proc_sys_call_handler+0x1bc/0x300[ 76.982331] proc_sys_write+0x17/0x20[ 76.982334] vfs_write+0x3d3/0x570[ 76.982342] ksys_write+0x73/0x160[ 76.982347] __x64_sys_write+0x1e/0x30[ 76.982352] do_syscall_64+0x35/0x80[ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcdFunct---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()This patch fixes a shift-out-of-bounds in brcmfmac that occurs inBIT(chiprev) when a 'chiprev' provided by the device is too large.It should also not be equal to or greater than BITS_PER_TYPE(u32)as we do bitwise AND with a u32 variable and BIT(chiprev). The patchadds a check that makes the function return NULL if that is the case.Note that the NULL case is later handled by the bus-specific caller,brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.Found by a modified version of syzkaller.UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.cshift exponent 151055786 is too large for 64-bit type 'long unsigned int'CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? pr---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/netiucv: Fix return type of netiucv_tx()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netiucv_tx, ^~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.Additionally, while in the area, remove a comment block that is nolonger relevant.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map()pci_get_device() will increase the reference count for the returnedpci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with itsreference count increased. We need to call pci_dev_put() to decrease thereference count. Let's add the missing pci_dev_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netsec: fix error handling in netsec_register_mdio()If phy_device_register() fails, phy_device_free() need be called toput refcount, so memory of phy device and device name can be freedin callback function.If get_phy_device() fails, mdiobus_unregister() need be called,or it will cause warning in mdiobus_free() and kobject is leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: fix UAF in hugetlb_handle_userfaultThe vma_lock and hugetlb_fault_mutex are dropped before handling userfaultand reacquire them again after handle_userfault(), but reacquire thevma_lock could lead to UAF[1,2] due to the following race,hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */Since the vma_lock will unlock immediately afterhugetlb_handle_userfault(), let's drop the unneeded lock and unlock inhugetlb_handle_userfault() to fix the issue.[1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/[2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix pci_device_is_present() for VFs by checking PFpci_device_is_present() previously didn't work for VFs because it reads theVendor and Device ID, which are 0xffff for VFs, which looks like theyaren't present. Check the PF instead.Wei Gong reported that if virtio I/O is in progress when the driver isunbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/Ooperation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0This happened because pci_device_is_present(VF) returned "false" invirtio_pci_remove(), so it called virtio_break_device(). The broken vqmeant that vring_interrupt() skipped the vq.callback() that would havecompleted the virtio I/O operation via virtblk_done().[bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: core: Fix kernel panic when remove non-standard SDIO cardSDIO tuple is only allocated for standard SDIO card, especially it causesmemory corruption issues when the non-standard SDIO card has removed, whichis because the card device's reference counter does not increase for it atsdio_init_func(), but all SDIO card device reference counter gets decreasedat sdio_release_func().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: associate skb with a device at txSyzkaller triggered flow dissector warning with the following:r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0[ 9.485929] skb_get_poff+0x53/0xa0[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20[ 9.485944] ? ppp_send_frame+0xc2/0x5b0[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0[ 9.485968] ? ppp_xmit_process+0x5b/0xb0[ 9.485974] ? ppp_write+0x12a/0x190[ 9.485981] ? do_iter_write+0x18e/0x2d0[ 9.485987] ? __import_iovec+0x30/0x130[ 9.485997] ? do_pwritev+0x1b6/0x240[ 9.486016] ? trace_hardirqs_on+0x47/0x50[ 9.486023] ? __x64_sys_pwritev+0x24/0x30[ 9.486026] ? do_syscall_64+0x3d/0x80[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcdFlow dissector tries to find skb net namespace either via deviceor via socket. Neigher is set in ppp_send_frame, so let's manuallyuse ppp->dev.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ipw2200: fix memory leak in ipw_wdev_init()In the error path of ipw_wdev_init(), exception value is returned, andthe memory applied for in the function is not released. Also the memoryis not released in ipw_pci_probe(). As a result, memory leakage occurs.So memory release needs to be added to the error path of ipw_wdev_init().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix deadlock due to mbcache entry corruptionWhen manipulating xattr blocks, we can deadlock infinitely loopinginside ext4_xattr_block_set() where we constantly keep finding xattrblock for reuse in mbcache but we are unable to reuse it because itsreference count is too big. This happens because cache entry for thexattr block is marked as reusable (e_reusable set) although itsreference count is too big. When this inconsistency happens, thisinconsistent state is kept indefinitely and so ext4_xattr_block_set()keeps retrying indefinitely.The inconsistent state is caused by non-atomic update of e_reusable bit.e_reusable is part of a bitfield and e_reusable update can race withupdate of e_referenced bit in the same bitfield resulting in loss of oneof the updates. Fix the problem by using atomic bitops instead.This bug has been around for many years, but it became *much* easierto hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattrblocks").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix "kernel NULL pointer dereference" errorWhen rxe_queue_init in the function rxe_qp_init_req fails,both qp->req.task.func and qp->req.task.arg are not initialized.Because of creation of qp fails, the function rxe_create_qp willcall rxe_qp_do_cleanup to handle allocated resource.Before calling __rxe_do_task, both qp->req.task.func andqp->req.task.arg should be checked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], forcommit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication inrds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a sectionprotected by lock_sock() without realizing that rds_send_xmit() might calllock_sock().We don't need to protect cancel_delayed_work_sync() using lock_sock(), foreven if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete,retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UPbit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: fix use after free in _ipmi_destroy_user()The intf_free() function frees the "intf" pointer so we cannotdereference it again on the next line.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix invalid address access when enabling SCAN log levelThe variable i is changed when setting random MAC address and causesinvalid address access when printing the value of pi->reqs[i]->reqid.We replace reqs index with ri to fix the issue.[ 136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000[ 136.737365] Mem abort info:[ 136.740172] ESR = 0x96000004[ 136.743359] Exception class = DABT (current EL), IL = 32 bits[ 136.749294] SET = 0, FnV = 0[ 136.752481] EA = 0, S1PTW = 0[ 136.755635] Data abort info:[ 136.758514] ISV = 0, ISS = 0x00000004[ 136.762487] CM = 0, WnR = 0[ 136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577[ 136.772265] [0000000000000000] pgd=0000000000000000[ 136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP[ 136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O)[ 136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb)[ 136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G O 4.19.42-00001-g531a5f5 #1[ 136.805532] Hardware name: Freescale i.MX8MQ EVK (DT)[ 136.810584] pstate: 60400005 (nZCv daif +PAN -UAO)[ 136.815429] pc : brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac][ 136.821811] lr : brcmf_pno_config_sched_scans+0x67c/0xa80 [brcmfmac][ 136.828162] sp : ffff00000e9a3880[ 136.831475] x29: ffff00000e9a3890 x28: ffff800020543400[ 136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0[ 136.842098] x25: ffff80002054345c x24: ffff800088d22400[ 136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8[ 136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400[ 136.858032] x19: ffff00000e9a3946 x18: 0000000000000000[ 136.863343] x17: 0000000000000000 x16: 0000000000000000[ 136.868655] x15: ffff0000093f3b37 x14: 0000000000000050[ 136.873966] x13: 0000000000003135 x12: 0000000000000000[ 136.879277] x11: 0000000000000000 x10: ffff000009a61888[ 136.884589] x9 : 000000000000000f x8 : 0000000000000008[ 136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d[ 136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942[ 136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8[ 136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000[ 136.911146] Call trace:[ 136.913623] brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac][ 136.919658] brcmf_pno_start_sched_scan+0xa4/0x118 [brcmfmac][ 136.925430] brcmf_cfg80211_sched_scan_start+0x80/0xe0 [brcmfmac][ 136.931636] nl80211_start_sched_scan+0x140/0x308 [cfg80211][ 136.937298] genl_rcv_msg+0x358/0x3f4[ 136.940960] netlink_rcv_skb+0xb4/0x118[ 136.944795] genl_rcv+0x34/0x48[ 136.947935] netlink_unicast+0x264/0x300[ 136.951856] netlink_sendmsg+0x2e4/0x33c[ 136.955781] __sys_sendto+0x120/0x19c
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ieee802154: don't warn zero-sized raw_sendmsg()syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1],for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting__dev_queue_xmit() with skb->len == 0.Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request wasable to return 0, don't call __dev_queue_xmit() if packet length is 0. ---------- #include #include int main(int argc, char *argv[]) { struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; struct iovec iov = { }; struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 }; sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0); return 0; } ----------Note that this might be a sign that commit fd1894224407c484 ("bpf: Don'tredirect packets with invalid pkt_len") should be reverted, forskb->len == 0 was acceptable for at least PF_IEEE802154 socket.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: stop mdx_raid1 thread when raid1 array run failedfail run raid1 array when we assemble array with the inactive disk only,but the mdx_raid1 thread were not stop, Even if the associated resourceshave been released. it will caused a NULL dereference when we do poweroff.This causes the following Oops: [ 287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070 [ 287.594762] #PF: supervisor read access in kernel mode [ 287.599912] #PF: error_code(0x0000) - not-present page [ 287.605061] PGD 0 P4D 0 [ 287.607612] Oops: 0000 [#1] SMP NOPTI [ 287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G U 5.10.146 #0 [ 287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022 [ 287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod] [ 287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ...... [ 287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202 [ 287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000 [ 287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800 [ 287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff [ 287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800 [ 287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500 [ 287.692052] FS: 0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000 [ 287.700149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0 [ 287.713033] Call Trace: [ 287.715498] raid1d+0x6c/0xbbb [raid1] [ 287.719256] ? __schedule+0x1ff/0x760 [ 287.722930] ? schedule+0x3b/0xb0 [ 287.726260] ? schedule_timeout+0x1ed/0x290 [ 287.730456] ? __switch_to+0x11f/0x400 [ 287.734219] md_thread+0xe9/0x140 [md_mod] [ 287.738328] ? md_thread+0xe9/0x140 [md_mod] [ 287.742601] ? wait_woken+0x80/0x80 [ 287.746097] ? md_register_thread+0xe0/0xe0 [md_mod] [ 287.751064] kthread+0x11a/0x140 [ 287.754300] ? kthread_park+0x90/0x90 [ 287.757974] ret_from_fork+0x1f/0x30In fact, when raid1 array run fail, we need to domd_unregister_thread() before raid1_free().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/lcs: Fix return type of lcs_start_xmit()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: silence the warning when evicting inode with dioread_nolockWhen evicting an inode with default dioread_nolock, it could be raced bythe unwritten extents converting kworker after writeback some newallocated dirty blocks. It convert unwritten extents to written, theextents could be merged to upper level and free extent blocks, so itcould mark the inode dirty again even this inode has been markedI_FREEING. But the inode->i_io_list check and warning inext4_evict_inode() missing this corner case. Fortunately,ext4_evict_inode() will wait all extents converting finished before thischeck, so it will not lead to inode use-after-free problem, every thingis OK besides this warning. The WARN_ON_ONCE was originally designedfor finding inode use-after-free issues in advance, but if we addcurrent dioread_nolock case in, it will become not quite useful, so fixthis warning by just remove this check. ====== WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227 ext4_evict_inode+0x875/0xc60 ... RIP: 0010:ext4_evict_inode+0x875/0xc60 ... Call Trace: evict+0x11c/0x2b0 iput+0x236/0x3a0 do_unlinkat+0x1b4/0x490 __x64_sys_unlinkat+0x4c/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fa933c1115b ======rm kworker ext4_end_io_end()vfs_unlink() ext4_unlink() ext4_convert_unwritten_io_end_vec() ext4_convert_unwritten_extents() ext4_map_blocks() ext4_ext_map_blocks() ext4_ext_try_to_merge_up() __mark_inode_dirty() check !I_FREEING locked_inode_to_wb_and_lock_list() iput() iput_final() evict() ext4_evict_inode() truncate_inode_pages_final() //wait release io_end inode_io_list_move_locked() ext4_release_io_end() trigger WARN_ON_ONCE()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: idmouse: fix an uninit-value in idmouse_openIn idmouse_create_image, if any ftip_command fails, it willgo to the reset label. However, this leads to the data inbulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the checkfor valid image incurs an uninitialized dereference.Fix this by moving the check before reset label since thischeck only be valid if the data after bulk_in_buffer[HEADER]has concrete data.Note that this is found by KMSAN, so only kernel compilationis tested.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfsDuring I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, ahard lockup similar to the call trace below may occur.The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timerinterrupts as expected, so change the strength of the spin lock to _irq.Kernel panic - not syncing: Hard LOCKUPCPU: 3 PID: 110402 Comm: cat Kdump: loadedexception RIP: native_queued_spin_lock_slowpath+91[IRQ stack] native_queued_spin_lock_slowpath at ffffffffb814e30b _raw_spin_lock at ffffffffb89a667a lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc] lpfc_cmf_timer at ffffffffc0abbc67 [lpfc] __hrtimer_run_queues at ffffffffb8184250 hrtimer_interrupt at ffffffffb8184ab0 smp_apic_timer_interrupt at ffffffffb8a026ba apic_timer_interrupt at ffffffffb8a01c4f[End of IRQ stack] apic_timer_interrupt at ffffffffb8a01c4f lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc] lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc] full_proxy_read at ffffffffb83e7fc3 vfs_read at ffffffffb833fe71 ksys_read at ffffffffb83402af do_syscall_64 at ffffffffb800430b entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()Running rcutorture with non-zero fqs_duration module parameter in akernel built with CONFIG_PREEMPTION=y results in the following splat:BUG: using __this_cpu_read() in preemptible [00000000]code: rcu_torture_fqs/398caller is __this_cpu_preempt_check+0x13/0x20CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+Call Trace:dump_stack_lvl+0x5b/0x86dump_stack+0x10/0x16check_preemption_disabled+0xe5/0xf0__this_cpu_preempt_check+0x13/0x20rcu_force_quiescent_state.part.0+0x1c/0x170rcu_force_quiescent_state+0x1e/0x30rcu_torture_fqs+0xca/0x160? rcu_torture_boost+0x430/0x430kthread+0x192/0x1d0? kthread_complete_and_exit+0x30/0x30ret_from_fork+0x22/0x30The problem is that rcu_force_quiescent_state() uses __this_cpu_read()in preemptible code instead of the proper raw_cpu_read(). This committherefore changes __this_cpu_read() to raw_cpu_read().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interruptI got a null-ptr-defer error report when I do the following testson the qemu platform:make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,CONFIG_SND_MTS64=mThen making test scripts:cat>test_mod1.sh< snd_mts64_interrupt+0x24/0xa0 [snd_mts64] parport_irq_handler+0x37/0x50 [parport] __handle_irq_event_percpu+0x39/0x190 handle_irq_event_percpu+0xa/0x30 handle_irq_event+0x2f/0x50 handle_edge_irq+0x99/0x1b0 __common_interrupt+0x5d/0x100 common_interrupt+0xa0/0xc0 asm_common_interrupt+0x22/0x40 RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30 parport_claim+0xbd/0x230 [parport] snd_mts64_probe+0x14a/0x465 [snd_mts64] platform_probe+0x3f/0xa0 really_probe+0x129/0x2c0 __driver_probe_device+0x6d/0xc0 driver_probe_device+0x1a/0xa0 __device_attach_driver+0x7a/0xb0 bus_for_each_drv+0x62/0xb0 __device_attach+0xe4/0x180 bus_probe_device+0x82/0xa0 device_add+0x550/0x920 platform_device_add+0x106/0x220 snd_mts64_attach+0x2e/0x80 [snd_mts64] port_check+0x14/0x20 [parport] bus_for_each_dev+0x6e/0xc0 __parport_register_driver+0x7c/0xb0 [parport] snd_mts64_module_init+0x31/0x1000 [snd_mts64] do_one_initcall+0x3c/0x1f0 do_init_module+0x46/0x1c6 load_module+0x1d8d/0x1e10 __do_sys_finit_module+0xa2/0xf0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 1 seconds..The mts wa not initialized during interrupt, we add check formts to fix this bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug_on in __es_tree_search caused by bad quota inodeWe got a issue as fllows:================================================================== kernel BUG at fs/ext4/extents_status.c:202! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 810 Comm: mount Not tainted 6.1.0-rc1-next-g9631525255e3 #352 RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0 RSP: 0018:ffffc90001227900 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8 RBP: ffff888177512ac8 R08: 47ffffffffffffff R09: 0000000000000001 R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10 R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000 FS: 00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ext4_es_cache_extent+0xe2/0x210 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_getblk+0x82/0x340 ext4_bread+0x14/0x110 ext4_quota_read+0xf0/0x180 v2_read_header+0x24/0x90 v2_check_quota_file+0x2f/0xa0 dquot_load_quota_sb+0x26c/0x760 dquot_load_quota_inode+0xa5/0x190 ext4_enable_quotas+0x14c/0x300 __ext4_fill_super+0x31cc/0x32c0 ext4_fill_super+0x115/0x2d0 get_tree_bdev+0x1d2/0x360 ext4_get_tree+0x19/0x30 vfs_get_tree+0x26/0xe0 path_mount+0x81d/0xfc0 do_mount+0x8d/0xc0 __x64_sys_mount+0xc0/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================================================Above issue may happen as follows:-------------------------------------ext4_fill_super ext4_orphan_cleanup ext4_enable_quotas ext4_quota_enable ext4_iget --> get error inode <5> ext4_ext_check_inode --> Wrong imode makes it escape inspection make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode dquot_load_quota_inode vfs_setup_quota_inode --> check pass dquot_load_quota_sb v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent __es_tree_search.isra.0 ext4_es_end --> Wrong extents trigger BUG_ONIn the above issue, s_usr_quota_inum is set to 5, but inode<5> containsincorrect imode and disordered extents. Because 5 is EXT4_BOOT_LOADER_INO,the ext4_ext_check_inode check in the ext4_iget function can be bypassed,finally, the extents that are not checked trigger the BUG_ON in the__es_tree_search function. To solve this issue, check whether the inode isbad_inode in vfs_setup_quota_inode().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-mfc: Clear workbit to handle error conditionDuring error on CLOSE_INSTANCE command, ctx_work_bits was not gettingcleared. During consequent mfc execution NULL pointer dereferencing ofthis context led to kernel panic. This patch fixes this issue by makingsure to clear ctx_work_bits always.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Don't leak netobj memory when gss_read_proxy_verf() fails
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: fix potential memory leak in wilc_mac_xmit()The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, adddev_kfree_skb() to fix it. Compile tested only.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: Fix potential resource leaksnfc_get_device() take reference for the device, add missingnfc_put_device() to release it when not need anymore.Also fix the style warnning by use error EOPNOTSUPP instead ofENOTSUPP.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: snic: Fix possible UAF in snic_tgt_create()Smatch reports a warning as follows:drivers/scsi/snic/snic_disc.c:307 snic_tgt_create() warn: '&tgt->list' not removed from listIf device_add() fails in snic_tgt_create(), tgt will be freed, buttgt->list will not be removed from snic->disc.tgt_list, then list traversalmay cause UAF.Remove from snic->disc.tgt_list before free().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: via-sdmmc: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value,it will lead two issues:1. The memory that allocated in mmc_alloc_host() is leaked.2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del().Fix this by checking the return value and goto error path whichwill call mmc_free_host().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pstore: Avoid kcore oops by vmap()ing with VM_IOREMAPAn oops can be induced by running 'cat /proc/kcore > /dev/null' ondevices using pstore with the ram backend because kmap_atomic() assumeslowmem pages are accessible with __va(). Unable to handle kernel paging request at virtual address ffffff807ff2b000 Mem abort info: ESR = 0x96000006 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 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000 [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: dm_integrity CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x110/0x260 lr : vread+0x194/0x294 sp : ffffffc013ee39d0 x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000 x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000 x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000 x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60 x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001 x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78 x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000 Call trace: __memcpy+0x110/0x260 read_kcore+0x584/0x778 proc_reg_read+0xb4/0xe4During early boot, memblock reserves the pages for the ramoops reservedmemory node in DT that would otherwise be part of the direct lowmemmapping. Pstore's ram backend reuses those reserved pages to change thememory type (writeback or non-cached) by passing the pages to vmap()(see pfn_to_page() usage in persistent_ram_vmap() for more details) withspecific flags. When read_kcore() starts iterating over the vmallocregion, it runs over the virtual address that vmap() returned forramoops. In aligned_vread() the virtual address is passed tovmalloc_to_page() which returns the page struct for the reserved lowmemarea. That lowmem page is passed to kmap_atomic(), which effectivelycalls page_to_virt() that assumes a lowmem page struct must be directlyaccessible with __va() and friends. These pages are mapped via vmap()though, and the lowmem mapping was never made, so accessing them via thelowmem virtual address oopses like above.Let's side-step this problem by passing VM_IOREMAP to vmap(). This willtell vread() to not include the ramoops region in the kcore. Instead thearea will look like a bunch of zeros. The alternative is to teach kmap()about vmalloc areas that intersect with lowmem. Presumably such a changeisn't a one-liner, and there isn't much interest in inspecting theramoops region in kcore files anyway, so the most expedient route istaken for now.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ipr: Fix WARNING in ipr_init()ipr_init() will not call unregister_reboot_notifier() whenpci_register_driver() fails, which causes a WARNING. Callunregister_reboot_notifier() when pci_register_driver() fails.notifier callback ipr_halt [ipr] already registeredWARNING: CPU: 3 PID: 299 at kernel/notifier.c:29notifier_chain_register+0x16d/0x230Modules linked in: ipr(+) xhci_pci_renesas xhci_hcd ehci_hcd usbcoreled_class gpu_sched drm_buddy video wmi drm_ttm_helper ttmdrm_display_helper drm_kms_helper drm drm_panel_orientation_quirksagpgart cfbftCPU: 3 PID: 299 Comm: modprobe Tainted: G W6.1.0-rc1-00190-g39508d23b672-dirty #332Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:notifier_chain_register+0x16d/0x230Call Trace: __blocking_notifier_chain_register+0x73/0xb0 ipr_init+0x30/0x1000 [ipr] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: rio: fix possible name leak in rio_register_mport()If device_register() returns error, the name allocated by dev_set_name()need be freed. It should use put_device() to give up the reference in theerror path, so that the name can be freed in kobject_cleanup(), andlist_del() is called to delete the port from rio_mports.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO messageCommit d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")extend the dialects from 3 to 4, but forget to decrease the extendedlength when specific the dialect, then the message length is largerthan expected.This maybe leak some info through network because not initialize themessage body.After apply this patch, the VALIDATE_NEGOTIATE_INFO message length isreduced from 28 bytes to 26 bytes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix a signed-integer-overflow bug in tcp_add_backlog()The type of sk_rcvbuf and sk_sndbuf in struct sock is int, andin tcp_add_backlog(), the variable limit is caculated by addingsk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max valueof int and overflow. This patch reduces the limit budget byhalving the sndbuf to solve this issue since ACK packets are muchsmaller than the payload.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas: avoid device tree lookups in rtas_os_term()rtas_os_term() is called during panic. Its behavior depends on a coupleof conditions in the /rtas node of the device tree, the traversal ofwhich entails locking and local IRQ state changes. If the kernel panicswhile devtree_lock is held, rtas_os_term() as currently written couldhang.Instead of discovering the relevant characteristics at panic time,cache them in file-static variables at boot. Note the lookup for"ibm,extended-os-term" is converted to of_property_read_bool() since itis a boolean property, not an RTAS function token.[mpe: Incorporate suggested change from Nick]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: OMAP2+: Fix memory leak in realtime_counter_init()The "sys_clk" resource is malloced by clk_get(),it is not released when the function return.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:objtool: Fix SEGFAULTfind_insn() will return NULL in case of failure. Check insn in orderto avoid a kernel Oops for NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state()When peer delete failed in a disconnect operation, use-after-freedetected by KFENCE in below log. It is because for each vdev_id andaddress, it has only one struct ath10k_peer, it is allocated inath10k_peer_map_event(). When connected to an AP, it has more thanone HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then thearray peer_map of struct ath10k will be set muti-elements to thesame ath10k_peer in ath10k_peer_map_event(). When peer delete failedin ath10k_sta_state(), the ath10k_peer will be free for the 1st peerid in array peer_map of struct ath10k, and then use-after-free happenedfor the 2nd peer id because they map to the same ath10k_peer.And clean up all peers in array peer_map for the ath10k_peer, thenuser-after-free disappearedpeer map event log:[ 306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e[ 306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33[ 306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246[ 306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198[ 306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166peer unmap event log:[ 435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING)[ 435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone)[ 435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246[ 435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198[ 435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166use-after-free log:[21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING)[21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110[21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed[21713.799968] ==================================================================[21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core][21713.799991][21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69):[21713.800010] ath10k_sta_state+0x265/0xb8a [ath10k_core][21713.800041] drv_sta_state+0x115/0x677 [mac80211][21713.800059] __sta_info_destroy_part2+0xb1/0x133 [mac80211][21713.800076] __sta_info_flush+0x11d/0x162 [mac80211][21713.800093] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211][21713.800110] ieee80211_mgd_deauth+0x26c/0x29b [mac80211][21713.800137] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211][21713.800153] nl80211_deauthenticate+0xf8/0x121 [cfg80211][21713.800161] genl_rcv_msg+0x38e/0x3be[21713.800166] netlink_rcv_skb+0x89/0xf7[21713.800171] genl_rcv+0x28/0x36[21713.800176] netlink_unicast+0x179/0x24b[21713.800181] netlink_sendmsg+0x3a0/0x40e[21713.800187] sock_sendmsg+0x72/0x76[21713.800192] ____sys_sendmsg+0x16d/0x1e3[21713.800196] ___sys_sendmsg+0x95/0xd1[21713.800200] __sys_sendmsg+0x85/0xbf[21713.800205] do_syscall_64+0x43/0x55[21713.800210] entry_SYSCALL_64_after_hwframe+0x44/0xa9[21713.800213][21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k[21713.800219][21713.800224] allocated by task 13 on cpu 0 at 21705.501373s:[21713.800241] ath10k_peer_map_event+0x7e/0x154 [ath10k_core][21713.800254] ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core][21713.800265] ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core][21713.800277] ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core][21713.800283] ath10k_pci_process_rx_cb+0x195/0x1d---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix use-after-free in ath9k_hif_usb_disconnect()This patch fixes a use-after-free in ath9k that occurs inath9k_hif_usb_disconnect() when ath9k_destroy_wmi() is trying to access'drv_priv' that has already been freed by ieee80211_free_hw(), called byath9k_htc_hw_deinit(). The patch moves ath9k_destroy_wmi() beforeieee80211_free_hw(). Note that urbs from the driver should be killedbefore freeing 'wmi' with ath9k_destroy_wmi() as their callbacks willaccess 'wmi'.Found by a modified version of syzkaller.==================================================================BUG: KASAN: use-after-free in ath9k_destroy_wmi+0x38/0x40Read of size 8 at addr ffff8881069132a0 by task kworker/0:1/7CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #131Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x8e/0xd1 print_address_description.constprop.0.cold+0x93/0x334 ? ath9k_destroy_wmi+0x38/0x40 ? ath9k_destroy_wmi+0x38/0x40 kasan_report.cold+0x83/0xdf ? ath9k_destroy_wmi+0x38/0x40 ath9k_destroy_wmi+0x38/0x40 ath9k_hif_usb_disconnect+0x329/0x3f0 ? ath9k_hif_usb_suspend+0x120/0x120 ? usb_disable_interface+0xfc/0x180 usb_unbind_interface+0x19b/0x7e0 ? usb_autoresume_device+0x50/0x50 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30 ? __device_link_del+0x370/0x370 ? usb_remove_ep_devs+0x43/0x80 ? remove_intf_ep_devs+0x112/0x1a0 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950 ? rcu_read_lock_sched_held+0xa1/0xd0 ? hub_port_debounce+0x2e0/0x2e0 ? check_irq_usage+0x860/0xf20 ? drain_workqueue+0x281/0x360 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x92b/0x1460 ? pwq_dec_nr_in_flight+0x330/0x330 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x95/0xe00 ? __kthread_parkme+0x115/0x1e0 ? process_one_work+0x1460/0x1460 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30The buggy address belongs to the page:page:ffffea00041a44c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106913flags: 0x200000000000000(node=0|zone=2)raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 7, ts 38347963444, free_ts 41399957635 prep_new_page+0x1aa/0x240 get_page_from_freelist+0x159a/0x27c0 __alloc_pages+0x2da/0x6a0 alloc_pages+0xec/0x1e0 kmalloc_order+0x39/0xf0 kmalloc_order_trace+0x19/0x120 __kmalloc+0x308/0x390 wiphy_new_nm+0x6f5/0x1dd0 ieee80211_alloc_hw_nm+0x36d/0x2230 ath9k_htc_probe_device+0x9d/0x1e10 ath9k_htc_hw_init+0x34/0x50 ath9k_hif_usb_firmware_cb+0x25f/0x4e0 request_firmware_work_func+0x131/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480page last free stack trace: free_pcp_prepare+0x3d3/0x7f0 free_unref_page+0x1e/0x3d0 device_release+0xa4/0x240 kobject_put+0x186/0x4c0 put_device+0x20/0x30 ath9k_htc_disconnect_device+0x1cf/0x2c0 ath9k_htc_hw_deinit+0x26/0x30 ath9k_hif_usb_disconnect+0x2d9/0x3f0 usb_unbind_interface+0x19b/0x7e0 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950 process_one_work+0x92b/0x1460Memory state around the buggy address: ffff888106913180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888106913200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff>ffff888---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: Prevent drm_copy_field() to attempt copying a NULL pointerThere are some struct drm_driver fields that are required by drivers sincedrm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.But it can be possible that a driver has a bug and did not set some of thefields, which leads to drm_copy_field() attempting to copy a NULL pointer:[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000[ +0.010955] Mem abort info:[ +0.002835] ESR = 0x0000000096000004[ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits[ +0.005395] SET = 0, FnV = 0[ +0.003113] EA = 0, S1PTW = 0[ +0.003182] FSC = 0x04: level 0 translation fault[ +0.004964] Data abort info:[ +0.002919] ISV = 0, ISS = 0x00000004[ +0.003886] CM = 0, WnR = 0[ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000[ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[ +0.006925] Internal error: Oops: 96000004 [#1] SMP...[ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ +0.007061] pc : __pi_strlen+0x14/0x150[ +0.003895] lr : drm_copy_field+0x30/0x1a4[ +0.004156] sp : ffff8000094b3a50[ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040[ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040[ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000[ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000[ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40[ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8[ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141[ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000[ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000[ +0.007240] Call trace:[ +0.002475] __pi_strlen+0x14/0x150[ +0.003537] drm_version+0x84/0xac[ +0.003448] drm_ioctl_kernel+0xa8/0x16c[ +0.003975] drm_ioctl+0x270/0x580[ +0.003448] __arm64_sys_ioctl+0xb8/0xfc[ +0.003978] invoke_syscall+0x78/0x100[ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4[ +0.004767] do_el0_svc+0x38/0x4c[ +0.003357] el0_svc+0x34/0x100[ +0.003185] el0t_64_sync_handler+0x11c/0x150[ +0.004418] el0t_64_sync+0x190/0x194[ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)[ +0.006180] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failedThere is a null-ptr-deref when mount.cifs over rdma: BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046 CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: dump_stack_lvl+0x34/0x44 kasan_report+0xad/0x130 rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe] execute_in_process_context+0x25/0x90 __rxe_cleanup+0x101/0x1d0 [rdma_rxe] rxe_create_qp+0x16a/0x180 [rdma_rxe] create_qp.part.0+0x27d/0x340 ib_create_qp_kernel+0x73/0x160 rdma_create_qp+0x100/0x230 _smbd_get_connection+0x752/0x20f0 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0The root cause of the issue is the socket create failed inrxe_qp_init_req().So move the reset rxe_qp_do_cleanup() after the NULL ptr check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()I got the the following report: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@62/regulators/extenIn of_get_regulator(), the node is returned from of_parse_phandle()with refcount incremented, after using it, of_node_put() need be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: close all race conditions in l2tp_tunnel_register()The code in l2tp_tunnel_register() is racy in several ways:1. It modifies the tunnel socket _after_ publishing it.2. It calls setup_udp_tunnel_sock() on an existing socket without locking.3. It changes sock lock class on fly, which triggers many syzbot reports.This patch amends all of them by moving socket initialization codebefore publishing and under sock lock. As suggested by Jakub, thel2tp lockdep class is not necessary as we can just switch tobh_lock_sock_nested().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: don't allow to overwrite ENDPOINT0 attributesA bad USB device is able to construct a service connection responsemessage with target endpoint being ENDPOINT0 which is reserved forHTC_CTRL_RSVD_SVC and should not be modified to be used for any otherservices.Reject such service connection responses.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix race on port outputassume the following setup on a single machine:1. An openvswitch instance with one bridge and default flows2. two network namespaces "server" and "client"3. two ovs interfaces "server" and "client" on the bridge4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues5. move the ends of the veth pairs to the respective network namespaces6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)7. start some http server on the server network namespace8. test if a client in the client namespace can reach the http serverwhen following the actions below the host has a chance of getting a cpustuck in a infinite loop:1. send a large amount of parallel requests to the http server (around 3000 curls should work)2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)there is a low chance that this will cause the below kernel cpu stuckmessage. If this does not happen just retry.Below there is also the output of bpftrace for the functions mentionedin the output.The series of events happening here is:1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net`3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs)5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 08. port deletion continues (but details are not relevant for this issue)9. at some future point the background task deletes the vportIf after 7. but before 9. a packet is send to the ovs vport (which isnot deleted at this point in time) which forwards it to the`dev_queue_xmit` flow even though the device is unregistering.In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there isa while loop (if the packet has a rx_queue recorded) that is infinite if`dev->real_num_tx_queues` is zero.To prevent this from happening we update `do_output` to handle deviceswithout carrier the same as if the device is not found (which wouldbe the code path after 9. is done).Additionally we now produce a warning in `skb_tx_hash` if we will hitthe infinite loop.bpftrace (first word is function name):__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2dp_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domainsof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-races around user->unix_inflight.user->unix_inflight is changed under spin_lock(unix_gc_lock),but too_many_unix_fds() reads it locklessly.Let's annotate the write/read accesses to user->unix_inflight.BUG: KCSAN: data-race in unix_attach_fds / unix_inflightwrite to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8value changed: 0x000000000000000c -> 0x000000000000000dReported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded staAvoid potential data corruption issues caused by uninitialized driverprivate data structures.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPFThe call to get_user_pages_fast() in vmci_host_setup_notify() can returnNULL context->notify_page causing a GPF. To avoid GPF check ifcontext->notify_page == NULL and return error if so.general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307]CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0Call Trace: vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: bdisp: Add missing check for create_workqueueAdd the check for the return value of the create_workqueuein order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix BUG_ON condition in btrfs_cancel_balancePausing and canceling balance can race to interrupt balance lead to BUG_ONpanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balancedoes not take this race scenario into account.However, the race condition has no other side effects. We can fix that.Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dcb: choose correct policy to parse DCB_ATTR_BCNThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],which is introduced in commit 859ee3c43812 ("DCB: Add support for DCBBCN"). Please see the comment in below codestatic int dcbnl_bcn_setcfg(...){ ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ...}That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nestattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But thefollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.By looking up the associated nla_policy for dcbnl_bcn_attrs. We can findthe beginning part of these two policies are "same".static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},};static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},};Therefore, the current code is buggy and thisnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and usethe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.Hence use the correct policy dcbnl_bcn_nest to parse the nestedtb[DCB_ATTR_BCN] TLV.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Handle EBUSY correctlyAs it is seqiv only handles the special return value of EINPROGERSS,which means that in all other cases it will free data related to therequest.However, as the caller of seqiv may specify MAY_BACKLOG, we also needto expect EBUSY and treat it in the same way. Otherwise backloggedrequests will trigger a use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfsAs the ramfs-based tmpfs uses ramfs_init_fs_context() for theinit_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb()to free it and avoid a memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add vlan_get_protocol_and_depth() helperBefore blamed commit, pskb_may_pull() was used insteadof skb_header_pointer() in __vlan_get_protocol() and friends.Few callers depended on skb->head being populated with MAC header,syzbot caught one of them (skb_mac_gso_segment())Add vlan_get_protocol_and_depth() to make the intent clearerand use it where sensible.This is a more generic fix than commit e9d3f80935b6("net/af_packet: make sure to pull mac header") which wasdealing with a similar issue.kernel BUG at include/linux/skbuff.h:2655 !invalid opcode: 0000 [#1] SMP KASANCPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419[] skb_gso_segment include/linux/netdevice.h:4819 [inline][] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725[] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313[] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029[] packet_snd net/packet/af_packet.c:3111 [inline][] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()This condition needs to match the previous "if (epcp->state == LISTEN) {"exactly to avoid a NULL dereference of either "listen_ep" or "ep". Theproblem is that "epcp" has been re-assigned so just testing"if (epcp->state == LISTEN) {" a second time is not sufficient.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Add lwtunnel encap size of all siblings in nexthop calculationIn function rt6_nlmsg_size(), the length of nexthop is calculatedby multipling the nexthop length of fib6_info and the number ofsiblings. However if the fib6_info has no lwtunnel but the siblingshave lwtunnels, the nexthop length is less than it should be, andit will trigger a warning in inet6_rt_notify() as follows:WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130......Call Trace: fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70 ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThis bug can be reproduced by script:ip -6 addr add 2002::2/64 dev ens2ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100for i in 10 20 30 40 50 60 70;do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i updonefor i in 10 20 30 40 50 60;do ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1dev ipv_$i metric 100doneip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100This patch fixes it by adding nexthop_len of every siblings usingrt6_nh_nlmsg_size().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: raspberrypi-ts - fix refcount leak in rpi_ts_proberpi_firmware_get() take reference, we need to release it in error pathsas well. Use devm_rpi_firmware_get() helper to handling the resources.Also remove the existing rpi_firmware_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phyFor some reason, the driver adding support for Exynos5420 MIPI phyback in 2016 wasn't used on Exynos5420, which caused a kernel panic.Add the proper compatible for it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urbThe syzbot fuzzer identified a problem in the usbnet driver:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc9000463f568 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0Call Trace: usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 [inline] netdev_start_xmit include/linux/netdevice.h:4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594...This bug is caused by the fact that usbnet trusts the bulk endpointaddresses its probe routine receives in the driver_info structure, andit does not check to see that these endpoints actually exist and havethe expected type and directions.The fix is simply to add such a check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix use-after-free in free_netdevWe do netif_napi_add() for all allocated q_vectors[], but potentiallydo netif_napi_del() for part of them, then kfree q_vectors and leaveinvalid pointers at dev->napi_list.Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) waitResult:[ 4093.900222] ==================================================================[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699[ 4093.900233][ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021[ 4093.900239] Call Trace:[ 4093.900244] dump_stack+0x71/0xab[ 4093.900249] print_address_description+0x6b/0x290[ 4093.900251] ? free_netdev+0x308/0x390[ 4093.900252] kasan_report+0x14a/0x2b0[ 4093.900254] free_netdev+0x308/0x390[ 4093.900261] iavf_remove+0x825/0xd20 [iavf][ 4093.900265] pci_device_remove+0xa8/0x1f0[ 4093.900268] device_release_driver_internal+0x1c6/0x460[ 4093.900271] pci_stop_bus_device+0x101/0x150[ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20[ 4093.900275] pci_iov_remove_virtfn+0x187/0x420[ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10[ 4093.900278] ? pci_get_subsys+0x90/0x90[ 4093.900280] sriov_disable+0xed/0x3e0[ 4093.900282] ? bus_find_device+0x12d/0x1a0[ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e][ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e][ 4093.900299] ? pci_get_device+0x7c/0x90[ 4093.900300] ? pci_get_subsys+0x90/0x90[ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210[ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e][ 4093.900318] sriov_numvfs_store+0x214/0x290[ 4093.900320] ? sriov_totalvfs_show+0x30/0x30[ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900323] ? __check_object_size+0x15a/0x350[ 4093.900326] kernfs_fop_write+0x280/0x3f0[ 4093.900329] vfs_write+0x145/0x440[ 4093.900330] ksys_write+0xab/0x160[ 4093.900332] ? __ia32_sys_read+0xb0/0xb0[ 4093.900334] ? fput_many+0x1a/0x120[ 4093.900335] ? filp_close+0xf0/0x130[ 4093.900338] do_syscall_64+0xa0/0x370[ 4093.900339] ? page_fault+0x8/0x30[ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 4093.900357] RIP: 0033:0x7f16ad4d22c0[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700[ 4093.9003---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip_vti: fix potential slab-use-after-free in decode_session6When ip_vti device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when ip_vti device sends IPv6 packets.As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix defrag path triggering jbd2 ASSERTcode path:ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERTcrash stacks:PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]AnalysisThis bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: callocfs2_journal_access_di() before ocfs2_journal_dirty() inocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() iscalled by ocfs2_split_extent() during defragmenting.How to fixFor ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller onlyneeds to call journal start/stop pair. The fix method is to removejournal access/dirty from __ocfs2_move_extent().The discussion for this patch:https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: don't leak memory if dev_set_name() failsWhen dev_set_name() fails, zcdn_create() doesn't free the newlyallocated resources. Do it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Release folio lock on fscache read hit.Under the current code, when cifs_readpage_worker is called, the callcontract is that the callee should unlock the page. This is documentedin the read_folio section of Documentation/filesystems/vfs.rst as:> The filesystem should unlock the folio once the read has completed,> whether it was successful or not.Without this change, when fscache is in use and cache hit occurs duringa read, the page lock is leaked, producing the following stack onsubsequent reads (via mmap) to the page:$ cat /proc/3890/task/12864/stack[<0>] folio_wait_bit_common+0x124/0x350[<0>] filemap_read_folio+0xad/0xf0[<0>] filemap_fault+0x8b1/0xab0[<0>] __do_fault+0x39/0x150[<0>] do_fault+0x25c/0x3e0[<0>] __handle_mm_fault+0x6ca/0xc70[<0>] handle_mm_fault+0xe9/0x350[<0>] do_user_addr_fault+0x225/0x6c0[<0>] exc_page_fault+0x84/0x1b0[<0>] asm_exc_page_fault+0x27/0x30This requires a reboot to resolve; it is a deadlock.Note however that the call to cifs_readpage_from_fscache does mark thepage clean, but does not free the folio lock. This happens in__cifs_readpage_from_fscache on success. Releasing the lock at thatpoint however is not appropriate as cifs_readahead also callscifs_readpage_from_fscache and *does* unconditionally release the lockafter its return. This change therefore effectively makescifs_readpage_worker work like cifs_readahead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix resource leak in device_add()When calling kobject_add() failed in device_add(), it will callcleanup_glue_dir() to free resource. But in kobject_add(),dev->kobj.parent has been set to NULL. This will cause resource leak.The process is as follows:device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()The preceding problem may cause insmod mac80211_hwsim.ko to failed.sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'Call Trace:dump_stack_lvl+0x8e/0xd1sysfs_warn_dup.cold+0x1c/0x29sysfs_create_dir_ns+0x224/0x280kobject_add_internal+0x2aa/0x880kobject_add+0x135/0x1a0get_device_parent+0x3d7/0x590device_add+0x2aa/0x1cb0device_create_groups_vargs+0x1eb/0x260device_create+0xdc/0x110mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]do_one_initcall+0x10f/0x630do_init_module+0x19f/0x5e0load_module+0x64b7/0x6eb0__do_sys_finit_module+0x140/0x200do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try toregister things with the same name in the same directory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: base: Free devm resources when unregistering a deviceIn the current code, devres_release_all() only gets called if the devicehas a bus and has been probed.This leads to issues when using bus-less or driver-less devices wherethe device might never get freed if a managed resource holds a referenceto the device. This is happening in the DRM framework for example.We should thus call devres_release_all() in the device_del() function tomake sure that the device-managed actions are properly executed when thedevice is unregistered, even if it has neither a bus nor a driver.This is effectively the same change than commit 2f8d16a996da ("devres:release resources on device_del()") that got reverted by commita525a3ddeaca ("driver core: free devres in device_release") overmemory leaks concerns.This patch effectively combines the two commits mentioned above torelease the resources both on device_del() and device_release() and getthe best of both worlds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix mid leak during reconnection after timeout thresholdWhen the number of responses with status of STATUS_IO_TIMEOUTexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnectthe connection. But we do not return the mid, or the creditsreturned for the mid, or reduce the number of in-flight requests.This bug could result in the server->in_flight count to go bad,and also cause a leak in the mids.This change moves the check to a few lines below where theresponse is decrypted, even of the response is read from thetransform header. This way, the code for returning the midscan be reused.Also, the cifs_reconnect was reconnecting just the transportconnection before. In case of multi-channel, this may not bewhat we want to do after several timeouts. Changed that toreconnect the session and the tree too.Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate nameMAX_STATUS_IO_TIMEOUT.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Avoid fcport pointer dereferenceKlocwork reported warning of NULL pointer may be dereferenced. The routineexits when sa_ctl is NULL and fcport is allocated after the exit call thuscausing NULL fcport pointer to dereference at the time of exit.To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi_si: fix a memleak in try_smi_init()Kmemleak reported the following leak info in try_smi_init():unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180The problem was that when an error occurred before handlers registrationand after allocating `new_smi->si_sm`, the variable wouldn't be freed inthe error handling afterwards since `shutdown_smi()` hadn't beenregistered yet. Fix it by adding a `kfree()` in the error handling pathin `try_smi_init()`.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix deletion race conditionSystem crash when using debug kernel due to link list corruption. The causeof the link list corruption is due to session deletion was allowed to queueup twice. Here's the internal trace that show the same port was allowed todouble queue for deletion on different cpu.20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 120808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1Move the clearing/setting of deleted flag lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix soft lockup in status_resyncstatus_resync() will calculate 'curr_resync - recovery_active' to showuser a progress bar like following:[============>........] resync = 61.4%'curr_resync' and 'recovery_active' is updated in md_do_sync(), andstatus_resync() can read them concurrently, hence it's possible that'curr_resync - recovery_active' can overflow to a huge number. In thiscase status_resync() will be stuck in the loop to print a large amountof '=', which will end up soft lockup.Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,this way resync in progress will be reported to user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.listWhen freeing slots in function slot_complete_v3_hw(), it is possible thatsas_dev.list is being traversed elsewhere, and it may trigger a NULLpointer exception, such as follows:==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task()==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe()[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32[ 7165.434926] sas: trying to find task 0x00000000769b5ba5[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored[ 7165.434976] Mem abort info:[ 7165.434982] ESR = 0x96000004[ 7165.434991] Exception class = DABT (current EL), IL = 32 bits[ 7165.434992] SET = 0, FnV = 0[ 7165.434993] EA = 0, S1PTW = 0[ 7165.434994] Data abort info:[ 7165.434994] ISV = 0, ISS = 0x00000004[ 7165.434995] CM = 0, WnR = 0[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2[ 7165.434998] [0000000000000000] pgd=0000000000000000[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw][ 7165.485247] sp : ffff00001d623bc0[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e[ 7165.567872] Call trace:[ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main][ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas][ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas][ 7165.592082] scsi_error_handler+0xb4/0x488[ 7165.596163] kthread+0x134/0x138[ 7165.599380] ret_from_fork+0x10/0x18[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)[ 7165.609004] kernel fault(0x1) notification starting on CPU 75[ 7165.700728] ---[ end trace fc042cbbea224efc ]---[ 7165.705326] Kernel panic - not syncing: Fatal exceptionTo fix the issue, grab sas_dev lock when traversing the members ofsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoidconcurrency of adding and deleting member. When ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: radio-shark: Add endpoint checksThe syzbot fuzzer was able to provoke a WARNING from the radio-shark2driver:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edacRBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387 shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88...The problem was caused by the fact that the driver does not checkwhether the endpoints it uses are actually present and have theappropriate types. This can be fixed by adding a simple check ofthese endpoints (and similarly for the radio-shark driver).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't dereference ACPI root object handleSince the commit referenced in the Fixes: tag below the VMBus client driveris walking the ACPI namespace up from the VMBus ACPI device to the ACPInamespace root object trying to find Hyper-V MMIO ranges.However, if it is not able to find them it ends trying to walk resources ofthe ACPI namespace root object itself.This object has all-ones handle, which causes a NULL pointer dereferencein the ACPI code (from dereferencing this pointer with an offset).This in turn causes an oops on boot with VMBus host implementations that donot provide Hyper-V MMIO ranges in their VMBus ACPI device or itsancestors.The QEMU VMBus implementation is an example of such implementation.I guess providing these ranges is optional, since all tested Windowsversions seem to be able to use VMBus devices without them.Fix this by explicitly terminating the lookup at the ACPI namespace rootobject.Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interfaceby default - they only do so if the KVM PV interface is missing ordisabled.Example stack trace of such oops:[ 3.710827] ? __die+0x1f/0x60[ 3.715030] ? page_fault_oops+0x159/0x460[ 3.716008] ? exc_page_fault+0x73/0x170[ 3.716959] ? asm_exc_page_fault+0x22/0x30[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0[ 3.723559] ? down_timeout+0x3a/0x60[ 3.724455] ? acpi_ns_get_node+0x3a/0x60[ 3.725412] acpi_ns_get_node+0x3a/0x60[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0[ 3.728400] acpi_rs_get_method_data+0x2b/0x70[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.732411] acpi_walk_resources+0x78/0xd0[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus][ 3.734802] platform_probe+0x3d/0x90[ 3.735684] really_probe+0x19b/0x400[ 3.736570] ? __device_attach_driver+0x100/0x100[ 3.737697] __driver_probe_device+0x78/0x160[ 3.738746] driver_probe_device+0x1f/0x90[ 3.739743] __driver_attach+0xc2/0x1b0[ 3.740671] bus_for_each_dev+0x70/0xc0[ 3.741601] bus_add_driver+0x10e/0x210[ 3.742527] driver_register+0x55/0xf0[ 3.744412] ? 0xffffffffc039a000[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixersmatch error:sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:we previously assumed 'rac97' could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible desc_ptr out-of-bounds accessesSanitize possible desc_ptr out-of-bounds accesses inses_enclosure_data_process().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()There is a memory leak reported by kmemleak: unreferenced object 0xffffc900003f0000 (size 12288): comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx] [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx] [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0The root cause is traced to an error-handling path in qla2x00_probe_one()when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" isused to record the port information and it is allocated inqla2x00_create_host(). However, it is not released in the error handlingpath "probe_failed".Fix this by freeing the memory of "scan.l" when an error occurs in theadapter initialization process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1The type of size is unsigned int, if size is 0x40000000, there willbe an integer overflow, size will be zero after size *= sizeof(uint32_t),will cause uninitialized memory to be referenced later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/vfio-ap: fix memory leak in vfio_ap device driverThe device release callback function invoked to release the matrix deviceuses the dev_get_drvdata(device *dev) function to retrieve thepointer to the vfio_matrix_dev object in order to free its storage. Theproblem is, this object is not stored as drvdata with the device; since thekfree function will accept a NULL pointer, the memory for thevfio_matrix_dev object is never freed.Since the device being released is contained within the vfio_matrix_devobject, the container_of macro will be used to retrieve its pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setupvariable *nplanes is provided by user via system call argument. Thepossible value of q_data->fmt->num_planes is 1-3, while the valueof *nplanes can be 1-8. The array access by index i can cause arrayout-of-bounds.Fix this bug by checking *nplanes against the array size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential use-after-free bugs in TCP_Server_Info::hostnameTCP_Server_Info::hostname may be updated once or many times duringreconnect, so protect its access outside reconnect path as well andthen prevent any potential use-after-free bugs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4)returns false, drbl_regs_memmap_p is not remapped. This passes a NULLpointer to iounmap(), which can trigger a WARN() on certain arches.When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4)returns true, drbl_regs_memmap_p may has been remapped andctrl_regs_memmap_p is not remapped. This is a resource leak and passes aNULL pointer to iounmap().To fix these issues, we need to add null checks before iounmap(), andchange some goto labels.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: free background tracker's queued work in btracker_destroyOtherwise the kernel can BUG with:[ 2245.426978] =============================================================================[ 2245.435155] BUG bt_work (Tainted: G B W ): Objects remaining in bt_work on __kmem_cache_shutdown()[ 2245.445233] -----------------------------------------------------------------------------[ 2245.445233][ 2245.454879] Slab 0x00000000b0ce2b30 objects=64 used=2 fp=0x000000000a3c6a4e flags=0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)[ 2245.467300] CPU: 7 PID: 10805 Comm: lvm Kdump: loaded Tainted: G B W 6.0.0-rc2 #19[ 2245.476078] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.5.6 10/06/2021[ 2245.483646] Call Trace:[ 2245.486100] [ 2245.488206] dump_stack_lvl+0x34/0x48[ 2245.491878] slab_err+0x95/0xcd[ 2245.495028] __kmem_cache_shutdown.cold+0x31/0x136[ 2245.499821] kmem_cache_destroy+0x49/0x130[ 2245.503928] btracker_destroy+0x12/0x20 [dm_cache][ 2245.508728] smq_destroy+0x15/0x60 [dm_cache_smq][ 2245.513435] dm_cache_policy_destroy+0x12/0x20 [dm_cache][ 2245.518834] destroy+0xc0/0x110 [dm_cache][ 2245.522933] dm_table_destroy+0x5c/0x120 [dm_mod][ 2245.527649] __dm_destroy+0x10e/0x1c0 [dm_mod][ 2245.532102] dev_remove+0x117/0x190 [dm_mod][ 2245.536384] ctl_ioctl+0x1a2/0x290 [dm_mod][ 2245.540579] dm_ctl_ioctl+0xa/0x20 [dm_mod][ 2245.544773] __x64_sys_ioctl+0x8a/0xc0[ 2245.548524] do_syscall_64+0x5c/0x90[ 2245.552104] ? syscall_exit_to_user_mode+0x12/0x30[ 2245.556897] ? do_syscall_64+0x69/0x90[ 2245.560648] ? do_syscall_64+0x69/0x90[ 2245.564394] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 2245.569447] RIP: 0033:0x7fe52583ec6b...[ 2245.646771] ------------[ cut here ]------------[ 2245.651395] kmem_cache_destroy bt_work: Slab cache still has objects when called from btracker_destroy+0x12/0x20 [dm_cache][ 2245.651408] WARNING: CPU: 7 PID: 10805 at mm/slab_common.c:478 kmem_cache_destroy+0x128/0x130Found using: lvm2-testsuite --only "cache-single-split.sh"Ben bisected and found that commit 0495e337b703 ("mm/slab_common:Deleting kobject in kmem_cache_destroy() without holdingslab_mutex/cpu_hotplug_lock") first exposed dm-cache's incompletecleanup of its background tracker work objects.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm flakey: fix a crash with invalid table lineThis command will crash with NULL pointer dereference: dmsetup create flakey --table \ "0 `blockdev --getsize /dev/ram0` flakey /dev/ram0 0 0 1 2 corrupt_bio_byte 512"Fix the crash by checking if arg_name is non-NULL before comparing it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set()tuning_ctl_set() might have buffer overrun at (X) if it didn't breakfrom loop by matching (A). static int tuning_ctl_set(...) { for (i = 0; i < TUNING_CTLS_COUNT; i++)(A) if (nid == ca0132_tuning_ctls[i].nid) break; snd_hda_power_up(...);(X) dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...); snd_hda_power_down(...); ^ return 1; }We will get below error by cppcheck sound/pci/hda/patch_ca0132.c:4229:2: note: After for loop, i has value 12 for (i = 0; i < TUNING_CTLS_COUNT; i++) ^ sound/pci/hda/patch_ca0132.c:4234:43: note: Array index out of bounds dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20, ^This patch cares non match case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: api - Use work queue in crypto_destroy_instanceThe function crypto_drop_spawn expects to be called in processcontext. However, when an instance is unregistered while it stillhas active users, the last user may cause the instance to be freedin atomic context.Fix this by delaying the freeing to a work queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: htc_hst: free skb in ath9k_htc_rx_msg() if there is no callback functionIt is stated that ath9k_htc_rx_msg() either frees the provided skb orpasses its management to another callback function. However, the skb isnot freed in case there is no another callback function, and Syzkaller wasable to cause a memory leak. Also minor comment fix.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: fix memory leak in mwifiex_histogram_read()Always free the zeroed page on return from 'mwifiex_histogram_read()'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register()When a file descriptor of pppol2tp socket is passed as file descriptorof UDP socket, a recursive deadlock occurs in l2tp_tunnel_register().This situation is reproduced by the following program:int main(void){ int sock; struct sockaddr_pppol2tp addr; sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP); if (sock < 0) { perror("socket"); return 1; } addr.sa_family = AF_PPPOX; addr.sa_protocol = PX_PROTO_OL2TP; addr.pppol2tp.pid = 0; addr.pppol2tp.fd = sock; addr.pppol2tp.addr.sin_family = PF_INET; addr.pppol2tp.addr.sin_port = htons(0); addr.pppol2tp.addr.sin_addr.s_addr = inet_addr("192.168.0.1"); addr.pppol2tp.s_tunnel = 1; addr.pppol2tp.s_session = 0; addr.pppol2tp.d_tunnel = 0; addr.pppol2tp.d_session = 0; if (connect(sock, (const struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("connect"); return 1; } return 0;}This program causes the following lockdep warning: ============================================ WARNING: possible recursive locking detected 6.2.0-rc5-00205-gc96618275234 #56 Not tainted -------------------------------------------- repro/8607 is trying to acquire lock: ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: l2tp_tunnel_register+0x2b7/0x11c0 but task is already holding lock: ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sk_lock-AF_PPPOX); lock(sk_lock-AF_PPPOX); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by repro/8607: #0: ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30 stack backtrace: CPU: 0 PID: 8607 Comm: repro Not tainted 6.2.0-rc5-00205-gc96618275234 #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x100/0x178 __lock_acquire.cold+0x119/0x3b9 ? lockdep_hardirqs_on_prepare+0x410/0x410 lock_acquire+0x1e0/0x610 ? l2tp_tunnel_register+0x2b7/0x11c0 ? lock_downgrade+0x710/0x710 ? __fget_files+0x283/0x3e0 lock_sock_nested+0x3a/0xf0 ? l2tp_tunnel_register+0x2b7/0x11c0 l2tp_tunnel_register+0x2b7/0x11c0 ? sprintf+0xc4/0x100 ? l2tp_tunnel_del_work+0x6b0/0x6b0 ? debug_object_deactivate+0x320/0x320 ? lockdep_init_map_type+0x16d/0x7a0 ? lockdep_init_map_type+0x16d/0x7a0 ? l2tp_tunnel_create+0x2bf/0x4b0 ? l2tp_tunnel_create+0x3c6/0x4b0 pppol2tp_connect+0x14e1/0x1a30 ? pppol2tp_put_sk+0xd0/0xd0 ? aa_sk_perm+0x2b7/0xa80 ? aa_af_perm+0x260/0x260 ? bpf_lsm_socket_connect+0x9/0x10 ? pppol2tp_put_sk+0xd0/0xd0 __sys_connect_file+0x14f/0x190 __sys_connect+0x133/0x160 ? __sys_connect_file+0x190/0x190 ? lockdep_hardirqs_on+0x7d/0x100 ? ktime_get_coarse_real_ts64+0x1b7/0x200 ? ktime_get_coarse_real_ts64+0x147/0x200 ? __audit_syscall_entry+0x396/0x500 __x64_sys_connect+0x72/0xb0 do_syscall_64+0x38/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdThis patch fixes the issue by getting/creating the tunnel beforelocking the pppol2tp socket.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amdgpu: validate offset_in_bo of drm_amdgpu_gem_vaThis is motivated by OOB access in amdgpu_vm_update_range whenoffset_in_bo+map_size overflows.v2: keep the validations in amdgpu_vm_bo_mapv3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map rather than to amdgpu_gem_va_ioctl
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: loop_set_status_from_info() check before assignmentIn loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit shouldbe checked before reassignment, because if an overflow error occurs, theoriginal correct value will be changed to the wrong value, and it will notbe changed back.More, the original patch did not solve the problem, the value was set andioctl returned an error, but the subsequent io used the value in the loopdriver, which still caused an alarm:loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it byupdating kcm_tx_msg(head)->last_skb if partial data is copied so that thefollowing sendmsg() will resume from the skb.However, we cannot know how many bytes were copied when we get the error.Thus, we could mess up the MSG_MORE queue.When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as wedo so for UDP by udp_flush_pending_frames().Even without this change, when the error occurred, the following sendmsg()resumed from a wrong skb and the queue was messed up. However, we haveyet to get such a report, and only syzkaller stumbled on it. So, thiscan be changed safely.Note this does not change SOCK_SEQPACKET behaviour.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: read sk->sk_family once in sk_mc_loop()syzbot is playing with IPV6_ADDRFORM quite a lot these days,and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()We have many more similar issues to fix.WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260Modules linked in:CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023Workqueue: events_power_efficient gc_workerRIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48RSP: 0018:ffffc90000388530 EFLAGS: 00010246RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83[] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline][] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211[] NF_HOOK_COND include/linux/netfilter.h:298 [inline][] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232[] dst_output include/net/dst.h:444 [inline][] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342[] qdisc_restart net/sched/sch_generic.c:407 [inline][] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415[] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125[] net_tx_action+0x7ac/0x940 net/core/dev.c:5247[] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599[] invoke_softirq kernel/softirq.c:430 [inline][] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683[] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix null-ptr-deref in raid10_sync_requestinit_resync() inits mempool and sets conf->have_replacemnt at the beginningof sync, close_sync() frees the mempool when sync is completed.After [1] recovery might be skipped and init_resync() is called butclose_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.The following is one way to reproduce the issue. 1) create a array, wait for resync to complete, mddev->recovery_cp is set to MaxSector. 2) recovery is woken and it is skipped. conf->have_replacement is set to 0 in init_resync(). close_sync() not called. 3) some io errors and rdev A is set to WantReplacement. 4) a new device is added and set to A's replacement. 5) recovery is woken, A have replacement, but conf->have_replacemnt is 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref occurs.Fix it by not calling init_resync() if recovery skipped.[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: early: xhci-dbc: Fix a potential out-of-bound memory accessIf xdbc_bulk_write() fails, the values in 'buf' can be anything. So thestring is not guaranteed to be NULL terminated when xdbc_trace() is called.Reserve an extra byte, which will be zeroed automatically because 'buf' isa static variable, in order to avoid troubles, should it happen.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Fix uninit-value in alauda_check_media()Syzbot got KMSAN to complain about access to an uninitialized value inthe alauda subdriver of usb-storage:BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0drivers/usb/storage/alauda.c:1137CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOSGoogle 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460The problem is that alauda_check_media() doesn't verify that its USBtransfer succeeded before trying to use the received data. Whatshould happen if the transfer fails isn't entirely clear, but areasonably conservative approach is to pretend that no media ispresent.A similar problem exists in a usb_stor_dbg() call inalauda_get_media_status(). In this case, when an error occurs thecall is redundant, because usb_stor_ctrl_transfer() already will printa debugging message.Finally, unrelated to the uninitialized memory access, is the factthat alauda_check_media() performs DMA to a buffer on the stack.Fortunately usb-storage provides a general purpose DMA-able buffer foruses like this. We'll use it instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: use internal state to free traffic IRQsIf the system tries to close the netdev while iavf_reset_task() isrunning, __LINK_STATE_START will be cleared and netif_running() willreturn false in iavf_reinit_interrupt_scheme(). This will result iniavf_free_traffic_irqs() not being called and a leak as follows: [7632.489326] remove_proc_entry: removing non-empty directory 'irq/999', leaking at least 'iavf-enp24s0f0v0-TxRx-0' [7632.490214] WARNING: CPU: 0 PID: 10 at fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0is shown when pci_disable_msix() is later called. Fix by using theinternal adapter state. The traffic IRQs will always exist ifstate == __IAVF_RUNNING.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate accesses to nlk->cb_runningBoth netlink_recvmsg() and netlink_native_seq_show() readnlk->cb_running locklessly. Use READ_ONCE() there.Add corresponding WRITE_ONCE() to netlink_dump() and__netlink_dump_start()syzbot reported:BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsgwrite to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:__netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399netlink_dump_start include/linux/netlink.h:308 [inline]rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg net/socket.c:747 [inline]sock_write_iter+0x1aa/0x230 net/socket.c:1138call_write_iter include/linux/fs.h:1851 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x463/0x760 fs/read_write.c:584ksys_write+0xeb/0x1a0 fs/read_write.c:637__do_sys_write fs/read_write.c:649 [inline]__se_sys_write fs/read_write.c:646 [inline]__x64_sys_write+0x42/0x50 fs/read_write.c:646do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017____sys_recvmsg+0x2db/0x310 net/socket.c:2718___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x00 -> 0x01
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of errorIf clk_get_rate() fails, the clk that has just been allocated needs to befreed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix missing hfs_bnode_get() in __hfs_bnode_createSyzbot found a kernel BUG in hfs_bnode_put(): kernel BUG at fs/hfs/bnode.c:466! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 3634 Comm: kworker/u4:5 Not tainted 6.1.0-rc7-syzkaller-00190-g97ee9d1c1696 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: writeback wb_workfn (flush-7:0) RIP: 0010:hfs_bnode_put+0x46f/0x480 fs/hfs/bnode.c:466 Code: 8a 80 ff e9 73 fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a0 fe ff ff 48 89 df e8 db 8a 80 ff e9 93 fe ff ff e8 a1 68 2c ff <0f> 0b e8 9a 68 2c ff 0f 0b 0f 1f 84 00 00 00 00 00 55 41 57 41 56 RSP: 0018:ffffc90003b4f258 EFLAGS: 00010293 RAX: ffffffff825e318f RBX: 0000000000000000 RCX: ffff8880739dd7c0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003b4f430 R08: ffffffff825e2d9b R09: ffffed10045157d1 R10: ffffed10045157d1 R11: 1ffff110045157d0 R12: ffff8880228abe80 R13: ffff88807016c000 R14: dffffc0000000000 R15: ffff8880228abe00 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa6ebe88718 CR3: 000000001e93d000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
hfs_write_inode+0x1bc/0xb40 write_inode fs/fs-writeback.c:1440 [inline] __writeback_single_inode+0x4d6/0x670 fs/fs-writeback.c:1652 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1878 __writeback_inodes_wb+0x125/0x420 fs/fs-writeback.c:1949 wb_writeback+0x440/0x7b0 fs/fs-writeback.c:2054 wb_check_start_all fs/fs-writeback.c:2176 [inline] wb_do_writeback fs/fs-writeback.c:2202 [inline] wb_workfn+0x827/0xef0 fs/fs-writeback.c:2235 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 The BUG_ON() is triggered at here:/* Dispose of resources used by a node */void hfs_bnode_put(struct hfs_bnode *node){ if (node) {
BUG_ON(!atomic_read(&node->refcnt)); <- we have issue here!!!! }}By tracing the refcnt, I found the node is created by hfs_bmap_alloc()with refcnt 1. Then the node is used by hfs_btree_write(). There is amissing of hfs_bnode_get() after find the node. The issue happened infollowing path: hfs_bmap_alloc hfs_bnode_find __hfs_bnode_create <- allocate a new node with refcnt 1. hfs_bnode_put <- decrease the refcnt hfs_btree_write hfs_bnode_find __hfs_bnode_create hfs_bnode_findhash <- find the node without refcnt increased. hfs_bnode_put <- trigger the BUG_ON() since refcnt is 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: do not hard code device address lenth in fdb dumpssyzbot reports that some netdev devices do not have a six bytesaddress [1]Replace ETH_ALEN by dev->addr_len.[1] (Case of a device where dev->addr_len = 4)BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169instrument_copy_to_user include/linux/instrumented.h:114 [inline]copyout+0xb8/0x100 lib/iov_iter.c:169_copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536copy_to_iter include/linux/uio.h:206 [inline]simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970sock_recvmsg_nosec net/socket.c:1019 [inline]sock_recvmsg net/socket.c:1040 [inline]____sys_recvmsg+0x283/0x7f0 net/socket.c:2722___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at:__nla_put lib/nlattr.c:1009 [inline]nla_put+0x1c6/0x230 lib/nlattr.c:1067nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019____sys_recvmsg+0x664/0x7f0 net/socket.c:2720___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at:slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716slab_alloc_node mm/slub.c:3451 [inline]__kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490kmalloc_trace+0x51/0x200 mm/slab_common.c:1057kmalloc include/linux/slab.h:559 [inline]__hw_addr_create net/core/dev_addr_lists.c:60 [inline]__hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118__dev_mc_add net/core/dev_addr_lists.c:867 [inline]dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708addrconf_type_change net/ipv6/addrconf.c:3731 [inline]addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699notifier_call_chain kernel/notifier.c:93 [inline]raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1935 [inline]call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906do_set_master net/core/rtnetlink.c:2626 [inline]rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]__rtnl_newlink net/core/rtnetlink.c:3660 [inline]rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0xf28/0x1230 net/netlink/af_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix potential use-after-free bug when trimming capsWhen trimming the caps and just after the 'session->s_cap_lock' isreleased in ceph_iterate_session_caps() the cap maybe removed byanother thread, and when using the stale cap memory in the callbacksit will trigger use-after-free crash.We need to check the existence of the cap just after the 'ci->i_ceph_lock'being acquired. And do nothing if it's already removed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: virtio - Fix race on data_avail and actual dataThe virtio rng device kicks off a new entropy request whenever thedata available reaches zero. When a new request occurs at the endof a read operation, that is, when the result of that request isonly needed by the next reader, then there is a race between thewriting of the new data and the next reader.This is because there is no synchronisation whatsoever between thewriter and the reader.Fix this by writing data_avail with smp_store_release and readingit with smp_load_acquire when we first enter read. The subsequentreads are safe because they're either protected by the first loadacquire, or by the completion mechanism.Also remove the redundant zeroing of data_idx in random_recv_done(data_idx must already be zero at this point) and data_avail inrequest_entropy (ditto).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while usingIPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)We had a similar report [1] for probably sk_memory_allocated_add()in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fixNULL pointer dereference") fixed it by setting .memory_allocated forudplite_prot and udplitev6_prot.To fix the variant, we need to set either .sysctl_wmem_offset or.sysctl_rmem.Now UDP and UDPLITE share the same value for .memory_allocated, so weuse the same .sysctl_wmem_offset for UDP and UDPLITE.[0]:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8bRSP: 0018:ffffc90005d7f450 EFLAGS: 00010246RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0Call Trace: __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82RIP: 0023:0xf7f21579Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vmci_host: fix a race condition in vmci_host_poll() causing GPFDuring fuzzing, a general protection fault is observed invmci_host_poll().general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf]RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926<- omitting registers ->Call Trace: lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162 add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22 poll_wait include/linux/poll.h:49 [inline] vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174 vfs_poll include/linux/poll.h:88 [inline] do_pollfd fs/select.c:873 [inline] do_poll fs/select.c:921 [inline] do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015 __do_sys_ppoll fs/select.c:1121 [inline] __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x46/0xb0Example thread interleaving that causes the general protection faultis as follows:CPU1 (vmci_host_poll) CPU2 (vmci_host_do_init_context)----- -----// Read uninitialized contextcontext = vmci_host_dev->context; // Initialize context vmci_host_dev->context = vmci_ctx_create(); vmci_host_dev->ct_type = VMCIOBJ_CONTEXT;if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) { // Dereferencing the wrong pointer poll_wait(..., &context->host_context);}In this scenario, vmci_host_poll() reads vmci_host_dev->context first,and then reads vmci_host_dev->ct_type to check thatvmci_host_dev->context is initialized. However, since these two readsare not atomically executed, there is a chance of a race condition asdescribed above.To fix this race condition, read vmci_host_dev->context after checkingthe value of vmci_host_dev->ct_type so that vmci_host_poll() alwaysreads an initialized context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix stack overflow when LRO is disabled for virtual interfacesWhen the virtual interface's feature is updated, it synchronizes theupdated feature for its own lower interface.This propagation logic should be worked as the iteration, not recursively.But it works recursively due to the netdev notification unexpectedly.This problem occurs when it disables LRO only for the team and bondinginterface type. team0 | +------+------+-----+-----+ | | | | |team1 team2 team3 ... team200If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGEevent to its own lower interfaces(team1 ~ team200).It is worked by netdev_sync_lower_features().So, the NETDEV_FEAT_CHANGE notification logic of each lower interfacework iteratively.But generated NETDEV_FEAT_CHANGE event is also sent to the upperinterface too.upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its ownlower interfaces again.lower and upper interfaces receive this event and generate thisevent again and again.So, the stack overflow occurs.But it is not the infinite loop issue.Because the netdev_sync_lower_features() updates features beforegenerating the NETDEV_FEAT_CHANGE event.Already synchronized lower interfaces skip notification logic.So, it is just the problem that iteration logic is changed to therecursive unexpectedly due to the notification mechanism.Reproducer:ip link add team0 type teamethtool -K team0 lro onfor i in {1..200}do ip link add team$i master team0 type team ethtool -K team$i lro ondoneethtool -K team0 lro offIn order to fix it, the notifier_ctx member of bonding/team is introduced.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()Klocwork reported warning of rport maybe NULL and will be dereferenced.rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.Check valid rport returned by fc_bsg_to_rport().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: set goal start correctly in ext4_mb_normalize_requestWe need to set ac_g_ex to notify the goal start used inext4_mb_find_by_goal. Set ac_g_ex instead of ac_f_ex inext4_mb_normalize_request.Besides we should assure goal start is in range [first_data_block,blocks_count) as ext4_mb_initialize_context does.[ Added a check to make sure size is less than ar->pright; otherwise we could end up passing an underflowed value of ar->pright - size to ext4_get_group_no_and_offset(), which will trigger a BUG_ON later on. - TYT ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between balance and cancel/pauseSyzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe reproducer is running a balance and a cancel or pause in parallel.The way balance finishes is a bit wonky, if we were paused we need tosave the balance_ctl in the fs_info, but clear it otherwise and cleanup.However we rely on the return values being specific errors, or having acancel request or no pause request. If balance completes and returns 0,but we have a pause or cancel request we won't do the appropriatecleanup, and then the next time we try to start a balance we'll tripthis ASSERT.The error handling is just wrong here, we always want to clean up,unless we got -ECANCELLED and we set the appropriate pause flag in theexclusive op. With this patch the reproducer ran for an hour withouttripping, previously it would trip in less than a few minutes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix the error "trying to register non-static key in rxe_cleanup_task"In the function rxe_create_qp(), rxe_qp_from_init() is called toinitialize qp, internally things like rxe_init_task are not setup untilrxe_qp_init_req().If an error occurred before this point then the unwind will callrxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()which will oops when trying to access the uninitialized spinlock.If rxe_init_task is not executed, rxe_cleanup_task will not be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting quota root from the dirty cow roots listWhen disabling quotas we are deleting the quota root from the listfs_info->dirty_cowonly_roots without taking the lock that protects it,which is struct btrfs_fs_info::trans_lock. This unsynchronized listmanipulation may cause chaos if there's another concurrent manipulationof this list, such as when adding a root to it withctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe quota root from that list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: fix possible soft lockup in __audit_inode_child()Tracefs or debugfs maybe cause hundreds to thousands of PATH records,too many PATH records maybe cause soft lockup.For example: 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4. mkdir /sys/kernel/debug/tracing/instances/testThere may be a soft lockup as follows: watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498] Kernel panic - not syncing: softlockup: hung tasks Call trace: dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340 __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140 __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180Therefore, we add cond_resched() to __audit_inode_child() to fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: dw_hdmi: cleanup drm encoder during unbindThis fixes a use-after-free crash during rmmod.The DRM encoder is embedded inside the larger rockchip_hdmi,which is allocated with the component. The component memorygets freed before the main drm device is destroyed. Fix itby running encoder cleanup before tearing down its container.[moved encoder cleanup above clk_disable, similar to bind-error-path]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Prevent handling any completions after qp destroyHW may generate completions that indicates QP is destroyed.Driver should not be scheduling any more completion handlersfor this QP, after the QP is destroyed. Since CQs are activeduring the QP destroy, driver may still schedule completionhandlers. This can cause a race where the destroy_cq and poll_cqrunning simultaneously.Snippet of kernel panic while doing bnxt_re driver load unload in loop.This indicates a poll after the CQ is freed. [77786.481636] Call Trace:[77786.481640] [77786.481644] bnxt_re_poll_cq+0x14a/0x620 [bnxt_re][77786.481658] ? kvm_clock_read+0x14/0x30[77786.481693] __ib_process_cq+0x57/0x190 [ib_core][77786.481728] ib_cq_poll_work+0x26/0x80 [ib_core][77786.481761] process_one_work+0x1e5/0x3f0[77786.481768] worker_thread+0x50/0x3a0[77786.481785] ? __pfx_worker_thread+0x10/0x10[77786.481790] kthread+0xe2/0x110[77786.481794] ? __pfx_kthread+0x10/0x10[77786.481797] ret_from_fork+0x2c/0x50To avoid this, complete all completion handlers before returning thedestroy QP. If free_cq is called soon after destroy_qp, IB stackwill cancel the CQ work before invoking the destroy_cq verb andthis will prevent any race mentioned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: do not allow gso_size to be set to GSO_BY_FRAGSOne missing check in virtio_net_hdr_to_skb() allowedsyzbot to crash kernels again [1]Do not allow gso_size to be set to GSO_BY_FRAGS (0xffff),because this magic value is used by the kernel.[1]general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 0 PID: 5039 Comm: syz-executor401 Not tainted 6.5.0-rc5-next-20230809-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:skb_segment+0x1a52/0x3ef0 net/core/skbuff.c:4500Code: 00 00 00 e9 ab eb ff ff e8 6b 96 5d f9 48 8b 84 24 00 01 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e ea 21 00 00 48 8b 84 24 00 01RSP: 0018:ffffc90003d3f1c8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 000000000001fffe RCX: 0000000000000000RDX: 000000000000000e RSI: ffffffff882a3115 RDI: 0000000000000070RBP: ffffc90003d3f378 R08: 0000000000000005 R09: 000000000000ffffR10: 000000000000ffff R11: 5ee4a93e456187d6 R12: 000000000001ffc6R13: dffffc0000000000 R14: 0000000000000008 R15: 000000000000ffffFS: 00005555563f2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020020000 CR3: 000000001626d000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:udp6_ufo_fragment+0x9d2/0xd50 net/ipv6/udp_offload.c:109ipv6_gso_segment+0x5c4/0x17b0 net/ipv6/ip6_offload.c:120skb_mac_gso_segment+0x292/0x610 net/core/gso.c:53__skb_gso_segment+0x339/0x710 net/core/gso.c:124skb_gso_segment include/net/gso.h:83 [inline]validate_xmit_skb+0x3a5/0xf10 net/core/dev.c:3625__dev_queue_xmit+0x8f0/0x3d60 net/core/dev.c:4329dev_queue_xmit include/linux/netdevice.h:3082 [inline]packet_xmit+0x257/0x380 net/packet/af_packet.c:276packet_snd net/packet/af_packet.c:3087 [inline]packet_sendmsg+0x24c7/0x5570 net/packet/af_packet.c:3119sock_sendmsg_nosec net/socket.c:727 [inline]sock_sendmsg+0xd9/0x180 net/socket.c:750____sys_sendmsg+0x6ac/0x940 net/socket.c:2496___sys_sendmsg+0x135/0x1d0 net/socket.c:2550__sys_sendmsg+0x117/0x1e0 net/socket.c:2579do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7ff27cdb34d9
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameterThe 'acpiid' buffer in the parse_ivrs_acpihid function may overflow,because the string specifier in the format string sscanf()has no width limitation.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting free space root from the dirty cow roots listWhen deleting the free space tree we are deleting the free space rootfrom the list fs_info->dirty_cowonly_roots without taking the lock thatprotects it, which is struct btrfs_fs_info::trans_lock.This unsynchronized list manipulation may cause chaos if there's anotherconcurrent manipulation of this list, such as when adding a root to itwith ctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe free space root from that list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: clean up in all error paths when enabling SR-IOVAfter commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removingthe igb module could hang or crash (depending on the machine) when themodule has been loaded with the max_vfs parameter set to some value != 0.In case of one test machine with a dual port 82580, this hang occurred:[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1[ 233.093257] igb 0000:41:00.1: IOV Disabled[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback)[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed[ 234.157244] igb 0000:41:00.0: IOV Disabled[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.[ 371.627489] Not tainted 6.4.0-dirty #2[ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this.[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0[ 371.650330] Call Trace:[ 371.653061] [ 371.655407] __schedule+0x20e/0x660[ 371.659313] schedule+0x5a/0xd0[ 371.662824] schedule_preempt_disabled+0x11/0x20[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10[ 371.678105] report_error_detected+0x25/0x1c0[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10[ 371.688618] pci_walk_bus+0x72/0x90[ 371.692519] pcie_do_recovery+0xb2/0x330[ 371.696899] aer_process_err_devices+0x117/0x170[ 371.702055] aer_isr+0x1c0/0x1e0[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10[ 371.715496] irq_thread_fn+0x20/0x60[ 371.719491] irq_thread+0xe6/0x1b0[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10[ 371.728255] ? __pfx_irq_thread+0x10/0x10[ 371.732731] kthread+0xe2/0x110[ 371.736243] ? __pfx_kthread+0x10/0x10[ 371.740430] ret_from_fork+0x2c/0x50[ 371.744428] The reproducer was a simple script: #!/bin/sh for i in `seq 1 5`; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb doneIt turned out that this could only be reproduce on 82580 (quad anddual-port), but not on 82576, i350 and i210. Further debugging showedthat igb_enable_sriov()'s call to pci_enable_sriov() is failing, becausedev->is_physfn is 0 on 82580.Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),igb_enable_sriov() jumped into the "err_out" cleanup branch. After thiscommit it only returned the error code.So the cleanup didn't take place, and the incorrect VF setup in theigb_adapter structure fooled the igb driver into assuming that VFs havebeen set up where no VF actually existed.Fix this problem by cleaning up again if pci_enable_sriov() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: speed up grant-table reclaimWhen a grant entry is still in use by the remote domain, Linux must putit on a deferred list. Normally, this list is very short, becausethe PV network and block protocols expect the backend to unmap the grantfirst. However, Qubes OS's GUI protocol is subject to the constraintsof the X Window System, and as such winds up with the frontend unmappingthe window first. As a result, the list can grow very large, resultingin a massive memory leak and eventual VM freeze.To partially solve this problem, make the number of entries that the VMwill attempt to free at each iteration tunable. The default is still10, but it can be overridden via a module parameter.This is Cc: stable because (when combined with appropriate userspacechanges) it fixes a severe performance and stability problem for QubesOS users.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/iommu: Fix notifiers being shared by PCI and VIO busesfail_iommu_setup() registers the fail_iommu_bus_notifier struct to bothPCI and VIO buses. struct notifier_block is a linked list node, so thiscauses any notifiers later registered to either bus type to also beregistered to the other since they share the same node.This causes issues in (at least) the vgaarb code, which registers anotifier for PCI buses. pci_notify() ends up being called on a viodevice, converted with to_pci_dev() even though it's not a PCI device,and finally makes a bad access in vga_arbiter_add_pci_device() asdiscovered with KASAN: BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00 Read of size 4 at addr c000000264c26fdc by task swapper/0/1 Call Trace: dump_stack_lvl+0x1bc/0x2b8 (unreliable) print_report+0x3f4/0xc60 kasan_report+0x244/0x698 __asan_load4+0xe8/0x250 vga_arbiter_add_pci_device+0x60/0xe00 pci_notify+0x88/0x444 notifier_call_chain+0x104/0x320 blocking_notifier_call_chain+0xa0/0x140 device_add+0xac8/0x1d30 device_register+0x58/0x80 vio_register_device_node+0x9ac/0xce0 vio_bus_scan_register_devices+0xc4/0x13c __machine_initcall_pseries_vio_device_init+0x94/0xf0 do_one_initcall+0x12c/0xaa8 kernel_init_freeable+0xa48/0xba8 kernel_init+0x64/0x400 ret_from_kernel_thread+0x5c/0x64Fix this by creating separate notifier_block structs for each bus type.[mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gvt: fix gvt debugfs destroyWhen gvt debug fs is destroyed, need to have a sane check if drmminor's debugfs root is still available or not, otherwise in case likedevice remove through unbinding, drm minor's debugfs directory hasalready been removed, then intel_gvt_debugfs_clean() would act upondangling pointer like below oops.i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state failed with error -2i915 0000:00:02.0: MDEV: RegisteredConsole: switching to colour dummy device 80x25i915 0000:00:02.0: MDEV: UnregisteringBUG: kernel NULL pointer dereference, address: 00000000000000a0PGD 0 P4D 0Oops: 0002 [#1] PREEMPT SMP PTICPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: G I 6.1.0-rc8+ #15Hardware name: Dell Inc. XPS 13 9350/0JXC1H, BIOS 1.13.0 02/10/2020RIP: 0010:down_write+0x1f/0x90Code: 1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01RSP: 0018:ffff9eb3036ffcc8 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0FS: 00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0Call Trace: simple_recursive_removal+0x9f/0x2a0 ? start_creating.part.0+0x120/0x120 ? _raw_spin_lock+0x13/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_clean+0x15/0x30 [kvmgt] intel_gvt_clean_device+0x49/0xe0 [kvmgt] intel_gvt_driver_remove+0x2f/0xb0 i915_driver_remove+0xa4/0xf0 i915_pci_remove+0x1a/0x30 pci_device_remove+0x33/0xa0 device_release_driver_internal+0x1b2/0x230 unbind_store+0xe0/0x110 kernfs_fop_write_iter+0x11b/0x1f0 vfs_write+0x203/0x3d0 ksys_write+0x63/0xe0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f6947cb5190Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89RSP: 002b:00007ffcbac45a28 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f6947cb5190RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97cR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001R13: 000000000000000d R14: 0000000000000000 R15: 0000555e358cb8e0 Modules linked in: kvmgtCR2: 00000000000000a0---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix DMA-API call trace on NVMe LS requestsThe following message and call trace was seen with debug kernels:DMA-API: qla2xxx 0000:41:00.0: device driver failed to check maperror [device address=0x00000002a3ff38d8] [size=1024 bytes] [mapped assingle]WARNING: CPU: 0 PID: 2930 at kernel/dma/debug.c:1017 check_unmap+0xf42/0x1990Call Trace: debug_dma_unmap_page+0xc9/0x100 qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]Remove DMA mapping from the driver altogether, as it is already done by FClayer. This prevents the warning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rcar_fdp1: Fix refcount leak in probe and remove functionrcar_fcp_get() take reference, which should be balanced withrcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove andthe error paths of fdp1_probe() to fix this.[hverkuil: resolve merge conflict, remove() is now void]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: rndis_host: Secure rndis_query check against int overflowVariables off and len typed as uint32 in rndis_query functionare controlled by incoming RNDIS response message thus theirvalue may be manipulated. Setting off to a unexpectetly largevalue will cause the sum with len and 8 to overflow and passthe implemented validation step. Consequently the responsepointer will be referring to a location past the expectedbuffer boundaries allowing information leakage e.g. viaRNDIS_OID_802_3_PERMANENT_ADDRESS OID.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix memory leak in error path of kcm_sendmsg()syzbot reported a memory leak like below:BUG: memory leakunreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [] alloc_skb include/linux/skbuff.h:1289 [inline] [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [] sock_sendmsg_nosec net/socket.c:725 [inline] [] sock_sendmsg+0x56/0xb0 net/socket.c:748 [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to appendnewly allocated skbs to 'head'. If some bytes are copied, an error occurred,and jumped to out_error label, 'last_skb' is left unmodified. A laterkcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the'head' frag_list and causing the leak.This patch fixes this issue by properly updating the last allocated skb in'last_skb'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inotify: Avoid reporting event with invalid wdWhen inotify_freeing_mark() races with inotify_handle_inode_event() itcan happen that inotify_handle_inode_event() sees that i_mark->wd gotalready reset to -1 and reports this value to userspace which canconfuse the inotify listener. Avoid the problem by validating that wd issensible (and pretend the mark got removed before the event gotgenerated otherwise).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeIn production we were seeing a variety of WARN_ON()'s in the extent_mapcode, specifically in btrfs_drop_extent_map_range() when we have to calladd_extent_mapping() for our second split.Consider the following extent map layout PINNED [0 16K) [32K, 48K)and then we call btrfs_drop_extent_map_range for [0, 36K), withskip_pinned == true. The initial loop will have start = 0 end = 36K len = 36Kwe will find the [0, 16k) extent, but since we are pinned we will skipit, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end;em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36Klen should instead be 20K. This is a problem when we find the nextextent at [32K, 48K), we need to split this extent to leave [36K, 48k),however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len);In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52Kand now we have an invalid extent_map in the tree that potentiallyoverlaps other entries in the extent map. Even in the non-overlappingcase we will have split->start set improperly, which will cause problemswith any block related calculations.We don't actually need len in this loop, we can simply use end as ourend point, and only adjust start up when we find a pinned extent we needto skip.Adjust the logic to do this, which keeps us from inserting an invalidextent map.We only skip_pinned in the relocation case, so this is relatively rare,except in the case where you are running relocation a lot, which canhappen with auto relocation on.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handlingCommit 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") fixeda build warning by turning a comment into a WARN_ON(), but it turns outthat syzbot then complains because it can trigger said warning with acorrupted hfs image.The warning actually does warn about a bad situation, but we are muchbetter off just handling it as the error it is. So rather than warnabout us doing bad things, stop doing the bad things and return -EIO.While at it, also fix a memory leak that was introduced by an earlierfix for a similar syzbot warning situation, and add a check for one casethat historically wasn't handled at all (ie neither comment norsubsequent WARN_ON).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_sdei: Fix sleep from invalid context BUGRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altratriggers: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20sdei_cpuhp_up() is called in the STARTING hotplug section,which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entryinstead to execute the cpuhp cb later, with preemption enabled.SDEI originally got its own cpuhp slot to allow interactingwith perf. It got superseded by pNMI and this early slot is notrelevant anymore. [1]Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on thecalling CPU. It is checked that preemption is disabled for them._ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.Preemption is enabled in those threads, but their cpumask is limitedto 1 CPU.Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cbdon't trigger them.Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI callwhich acts on the calling CPU.[1]:https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:keys: Fix linking a duplicate key to a keyring's assoc_arrayWhen making a DNS query inside the kernel using dns_query(), the requestcode can in rare cases end up creating a duplicate index key in theassoc_array of the destination keyring. It is eventually found bya BUG_ON() check in the assoc_array implementation and results ina crash.Example report:[2158499.700025] kernel BUG at ../lib/assoc_array.c:652![2158499.700039] invalid opcode: 0000 [#1] SMP PTI[2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3[2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020[2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs][2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40[2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff <0f> 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f[2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282[2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005[2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000[2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000[2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28[2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740[2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000[2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0[2158499.700702] Call Trace:[2158499.700741] ? key_alloc+0x447/0x4b0[2158499.700768] ? __key_link_begin+0x43/0xa0[2158499.700790] __key_link_begin+0x43/0xa0[2158499.700814] request_key_and_link+0x2c7/0x730[2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver][2158499.700873] ? key_default_cmp+0x20/0x20[2158499.700898] request_key_tag+0x43/0xa0[2158499.700926] dns_query+0x114/0x2ca [dns_resolver][2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs][2158499.701164] ? scnprintf+0x49/0x90[2158499.701190] ? __switch_to_asm+0x40/0x70[2158499.701211] ? __switch_to_asm+0x34/0x70[2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs][2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs][2158499.701632] process_one_work+0x1f8/0x3e0[2158499.701658] worker_thread+0x2d/0x3f0[2158499.701682] ? process_one_work+0x3e0/0x3e0[2158499.701703] kthread+0x10d/0x130[2158499.701723] ? kthread_park+0xb0/0xb0[2158499.701746] ret_from_fork+0x1f/0x40The situation occurs as follows:* Some kernel facility invokes dns_query() to resolve a hostname, for example, "abcdef". The function registers its global DNS resolver cache as current->cred.thread_keyring and passes the query to request_key_net() -> request_key_tag() -> request_key_and_link().* Function request_key_and_link() creates a keyring_search_context object. Its match_data.cmp method gets set via a call to type->match_preparse() (resolves to dns_resolver_match_preparse()) to dns_resolver_cmp().* Function request_key_and_link() continues and invokes search_process_keyrings_rcu() which returns that a given key was not found. The control is then passed to request_key_and_link() -> construct_alloc_key().* Concurrently to that, a second task similarly makes a DNS query for "abcdef." and its result gets inserted into the DNS resolver cache.* Back on the first task, function construct_alloc_key() first runs __key_link_begin() to determine an assoc_array_edit operation to insert a new key. Index keys in the array are compared exactly as-is, using keyring_compare_object(). The operation ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsit: Free cmds before session freeCommands from recovery entries are freed after session has been closed.That leads to use-after-free at command free or NPE with such call trace:Time2Retain timer expired for SID: 1, cleaning up iSCSI session.BUG: kernel NULL pointer dereference, address: 0000000000000140RIP: 0010:sbitmap_queue_clear+0x3a/0xa0Call Trace: target_release_cmd_kref+0xd1/0x1f0 [target_core_mod] transport_generic_free_cmd+0xd1/0x180 [target_core_mod] iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod] iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod] iscsit_close_session+0x13a/0x140 [iscsi_target_mod] iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod] call_timer_fn+0x24/0x140Move cleanup of recovery enrties to before session freeing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: fix pin_assignment_showThis patch fixes negative indexing of buf array in pin_assignment_showwhen get_current_pin_assignments returns 0 i.e. no compatible pinassignments are found.BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c...Call trace:dump_backtrace+0x110/0x204dump_stack_lvl+0x84/0xbcprint_report+0x358/0x974kasan_report+0x9c/0xfc__do_kernel_fault+0xd4/0x2d4do_bad_area+0x48/0x168do_tag_check_fault+0x24/0x38do_mem_abort+0x6c/0x14cel1_abort+0x44/0x68el1h_64_sync_handler+0x64/0xa4el1h_64_sync+0x78/0x7cpin_assignment_show+0x26c/0x33cdev_attr_show+0x50/0xc0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.This patch introduces a possible null-ptr-def problem. Revert it. And thefixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:btsdio: fix use after free bug in btsdio_remove due to race condition").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: fix out-of-bounds access in tty_driver_lookup_tty()When specifying an invalid console= device like console=tty3270,tty_driver_lookup_tty() returns the tty struct without checkingwhether index is a valid number.To reproduce:qemu-system-x86_64 -enable-kvm -nographic -serial mon:stdio \-kernel ../linux-build-x86/arch/x86/boot/bzImage \-append "console=ttyS0 console=tty3270"This crashes with:[ 0.770599] BUG: kernel NULL pointer dereference, address: 00000000000000ef[ 0.771265] #PF: supervisor read access in kernel mode[ 0.771773] #PF: error_code(0x0000) - not-present page[ 0.772609] Oops: 0000 [#1] PREEMPT SMP PTI[ 0.774878] RIP: 0010:tty_open+0x268/0x6f0[ 0.784013] chrdev_open+0xbd/0x230[ 0.784444] ? cdev_device_add+0x80/0x80[ 0.784920] do_dentry_open+0x1e0/0x410[ 0.785389] path_openat+0xca9/0x1050[ 0.785813] do_filp_open+0xaa/0x150[ 0.786240] file_open_name+0x133/0x1b0[ 0.786746] filp_open+0x27/0x50[ 0.787244] console_on_rootfs+0x14/0x4d[ 0.787800] kernel_init_freeable+0x1e4/0x20d[ 0.788383] ? rest_init+0xc0/0xc0[ 0.788881] kernel_init+0x11/0x120[ 0.789356] ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: fix race condition UAF in i915_perf_add_config_ioctlUserspace can guess the id value and try to race oa_config object creationwith config remove, resulting in a use-after-free if we dereference theobject after unlocking the metrics_lock. For that reason, unlocking themetrics_lock must be done after we are done dereferencing the object.[tursulin: Manually added stable tag.](cherry picked from commit 49f6f6483b652108bcb73accd0204a464b922395)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix warning in trace_buffered_event_disable()Warning happened in trace_buffered_event_disable() at WARN_ON_ONCE(!trace_buffered_event_ref) Call Trace: ? __warn+0xa5/0x1b0 ? trace_buffered_event_disable+0x189/0x1b0 __ftrace_event_enable_disable+0x19e/0x3e0 free_probe_data+0x3b/0xa0 unregister_ftrace_function_probe_func+0x6b8/0x800 event_enable_func+0x2f0/0x3d0 ftrace_process_regex.isra.0+0x12d/0x1b0 ftrace_filter_write+0xe6/0x140 vfs_write+0x1c9/0x6f0 [...]The cause of the warning is in __ftrace_event_enable_disable(),trace_buffered_event_enable() was called once whiletrace_buffered_event_disable() was called twice.Reproduction script show as below, for analysis, see the comments: ``` #!/bin/bash cd /sys/kernel/tracing/ # 1. Register a 'disable_event' command, then: # 1) SOFT_DISABLED_BIT was set; # 2) trace_buffered_event_enable() was called first time; echo 'cmdline_proc_show:disable_event:initcall:initcall_finish' > \ set_ftrace_filter # 2. Enable the event registered, then: # 1) SOFT_DISABLED_BIT was cleared; # 2) trace_buffered_event_disable() was called first time; echo 1 > events/initcall/initcall_finish/enable # 3. Try to call into cmdline_proc_show(), then SOFT_DISABLED_BIT was # set again!!! cat /proc/cmdline # 4. Unregister the 'disable_event' command, then: # 1) SOFT_DISABLED_BIT was cleared again; # 2) trace_buffered_event_disable() was called second time!!! echo '!cmdline_proc_show:disable_event:initcall:initcall_finish' > \ set_ftrace_filter ```To fix it, IIUC, we can change to call trace_buffered_event_enable() atfist time soft-mode enabled, and call trace_buffered_event_disable() atlast time soft-mode disabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: sisusbvga: Add endpoint checksThe syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000003R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869...The problem was caused by the fact that the driver does not checkwhether the endpoints it uses are actually present and have theappropriate types. This can be fixed by adding a simple check ofthe endpoints.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Fix oops for port->pm on uart_change_pm()Unloading a hardware specific 8250 driver can produce error "Unable tohandle kernel paging request at virtual address" about ten seconds afterunloading the driver. This happens on uart_hangup() callinguart_change_pm().Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on portspecific driver unbind") was only a partial fix. If the hardware specificdriver has initialized port->pm function, we need to clear port->pm too.Just reinitializing port->ops does not do this. Otherwise serial8250_pm()will call port->pm() instead of serial8250_do_pm().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: EC: Fix oops when removing custom query handlersWhen removing custom query handlers, the handler might stillbe used inside the EC query workqueue, causing a kernel oopsif the module holding the callback function was already unloaded.Fix this by flushing the EC query workqueue when removingcustom query handlers.Tested on a Acer Travelmate 4002WLMi
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/sysv: Null check to prevent null-ptr-deref bugsb_getblk(inode->i_sb, parent) return a null ptr and taking lock onthat leads to the null-ptr-deref bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix NULL dereference in error handlingSmatch reported:drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()warn: missing unwind goto?At this point in the function, nothing has been allocated so we can returndirectly. In particular the "qedf->global_queues" have not been allocatedso calling qedf_free_global_queues() will lead to a NULL dereference whenwe check if (!gl[i]) and "gl" is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: bus: verify partner exists in typec_altmode_attentionSome usb hubs will negotiate DisplayPort Alt mode with the devicebut will then negotiate a data role swap after entering the altmode. The data role swap causes the device to unregister all altmodes, however the usb hub will still send Attention messageseven after failing to reregister the Alt Mode. type_altmode_attentioncurrently does not verify whether or not a device's altmode partnerexists, which results in a NULL pointer error when dereferencingthe typec_altmode and typec_altmode_ops belonging to the altmodepartner.Verify the presence of a device's altmode partner before sendingthe Attention message to the Alt Mode driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix deadlock when converting an inline directory in nojournal modeIn no journal mode, ext4_finish_convert_inline_dir() can self-deadlockby calling ext4_handle_dirty_dirblock() when it already has taken thedirectory lock. There is a similar self-deadlock inext4_incvert_inline_data_nolock() for data files which we'll fix atthe same time.A simple reproducer demonstrating the problem: mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64 mount -t ext4 -o dirsync /dev/vdc /vdc cd /vdc mkdir file0 cd file0 touch file0 touch file1 attr -s BurnSpaceInEA -V abcde . touch supercalifragilisticexpialidocious
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix potential null-ptr-deref in device_add()I got the following null-ptr-deref report while doing fault injection test:BUG: kernel NULL pointer dereference, address: 0000000000000058CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+RIP: 0010:klist_put+0x2d/0xd0Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482]This is how it happened:w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device. // error path bus_remove_device() // The dev->driver is not null, but driver is not bound. __device_release_driver() klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref. // normal path bus_probe_device() // It's not called yet. device_bind_driver()If dev->driver is set, in the error path after calling bus_add_device()in device_add(), bus_remove_device() is called, then the device will bedetached from driver. But device_bind_driver() is not called yet, so itcauses null-ptr-deref while access the 'knode_driver'. To fix this, setdev->driver to null in the error path before calling bus_remove_device().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible addl_desc_ptr out-of-bounds accessesSanitize possible addl_desc_ptr out-of-bounds accesses inses_enclosure_data_process().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: PVH guests have their ACPI tables constructed by the toolstack. Theconstruction involves building the tables in local memory, which arethen copied into guest memory. While actually used parts of the localmemory are filled in correctly, excess space that is being allocated isleft with its prior contents.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- xen-libs > 0-0 (version in image is 4.12.4_62-3.130.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.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:
- 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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxslt1 > 0-0 (version in image is 1.1.28-17.18.1).
-
Description: Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glibc > 0-0 (version in image is 2.22-114.40.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check dce_hwseq before dereferencing it[WHAT]hws was checked for null earlier in dce110_blank_stream, indicating hwscan be null, and should be checked whenever it is used.(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix oops due to non-existence of prealloc backlog structIf an AF_RXRPC service socket is opened and bound, but calls arepreallocated, then rxrpc_alloc_incoming_call() will oops because therxrpc_backlog struct doesn't get allocated until the first preallocation ismade.Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is nobacklog struct. This will cause the incoming call to be aborted.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Fix OOB read due to missing payload bound checkCurrently, The event_seq_changed() handler processes a variable numberof properties sent by the firmware. The number of properties is indicatedby the firmware and used to iterate over the payload. However, thepayload size is not being validated against the actual message length.This can lead to out-of-bounds memory access if the firmware provides aproperty count that exceeds the data available in the payload. Such acondition can result in kernel crashes or potential information leaks ifmemory beyond the buffer is accessed.Fix this by properly validating the remaining size of the payload beforeeach property access and updating bounds accordingly as properties areparsed.This ensures that property parsing is safely bounded within the receivedmessage buffer and protects against malformed or malicious firmwarebehavior.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()The buffer length check before calling uvc_parse_format() only ensuredthat the buffer has at least 3 bytes (buflen > 2), buf the functionaccesses buffer[3], requiring at least 4 bytes.This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.Fix it by checking that the buffer has at least 4 bytes inuvc_parse_format().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix race between polling and detachingsyzbot reports a use-after-free in comedi in the below link, which isdue to comedi gladly removing the allocated async area even though pollrequests are still active on the wait_queue_head inside of it. This cancause a use-after-free when the poll entries are later triggered orremoved, as the memory for the wait_queue_head has been freed. We needto check there are no tasks queued on any of the subdevices' wait queuesbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`ioctl.Tasks will read-lock `dev->attach_lock` before adding themselves to thesubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctlhandler by write-locking `dev->attach_lock` before checking that all ofthe subdevices are safe to be deleted. This includes testing for anysleepers on the subdevices' wait queues. It remains locked until thedevice has been detached. This requires the `comedi_device_detach()`function to be refactored slightly, moving the bulk of it into newfunction `comedi_device_detach_locked()`.Note that the refactor of `comedi_device_detach()` results in`comedi_device_cancel_all()` now being called while `dev->attach_lock`is write-locked, which wasn't the case previously, but that does notmatter.Thanks to Jens Axboe for diagnosing the problem and co-developing thispatch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix uninited ptr deref in block/scsi layoutThe error occurs on the third attempt to encode extents. When functionext_tree_prepare_commit() reallocates a larger buffer to retry encodingextents, the "layoutupdate_pages" page array is initialized only after theretry loop. But ext_tree_free_commitdata() is called on every iterationand tries to put pages in the array, thus dereferencing uninitializedpointers.An additional problem is that there is no limit on the maximum possiblebuffer_size. When there are too many extents, the client may create alayoutcommit that is larger than the maximum possible RPC size acceptedby the server.During testing, we observed two typical scenarios. First, one memory pagefor extents is enough when we work with small files, append data to theend of the file, or preallocate extents before writing. But when we filla new large file without preallocating, the number of extents can be huge,and counting the number of written extents in ext_tree_encode_commit()does not help much. Since this number increases even more betweenunlocking and locking of ext_tree, the reallocated buffer may not belarge enough again and again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix refcount leak on table dumpThere is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...While its very unlikely, its possible that ct == last.If this happens, then the refcount of ct was already incremented.This 2nd increment is never undone.This prevents the conntrack object from being released, which in turnkeeps prevents cnet->count from dropping back to 0.This will then block the netns dismantle (or conntrack rmmod) asnf_conntrack_cleanup_net_list() will wait forever.This can be reproduced by running conntrack_resize.sh selftest in a loop.It takes ~20 minutes for me on a preemptible kernel on average beforeI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);But this reference counting isn't needed in the first place.We can just store a cookie value instead.A followup patch will do the same for ctnetlink_exp_dump_table,it looks to me as if this has the same problem and likectnetlink_dump_table, we only need a 'skip hint', not the actualobject so we can apply the same cookie strategy there as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()Lei Lu recently reported that nfsd4_setclientid_confirm() did not checkthe return value from get_client_locked(). a SETCLIENTID_CONFIRM couldrace with a confirmed client expiring and fail to get a reference. Thatcould later lead to a UAF.Fix this by getting a reference early in the case where there is anextant confirmed client. If that fails then treat it as if there were noconfirmed client found at all.In the case where the unconfirmed client is expiring, just fail andreturn the result from get_client_locked().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernelbuffer is allocated to hold `insn->n` samples (each of which is an`unsigned int`). For some instruction types, `insn->n` samples arecopied back to user-space, unless an error code is being returned. Theproblem is that not all the instruction handlers that need to returndata to userspace fill in the whole `insn->n` samples, so that there isan information leak. There is a similar syzbot report for`do_insnlist_ioctl()`, although it does not have a reproducer for it atthe time of writing.One culprit is `insn_rw_emulate_bits()` which is used as the handler for`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not havea specific handler for that instruction, but do have an `INSN_BITS`handler. For `INSN_READ` it only fills in at most 1 sample, so if`insn->n` is greater than 1, the remaining `insn->n - 1` samples copiedto userspace will be uninitialized kernel data.Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. Itnever returns an error, even if it fails to fill the buffer.Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making surethat uninitialized parts of the allocated buffer are zeroed beforehandling each instruction.Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fixreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is notalways necessary to clear the whole buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Make insn_rw_emulate_bits() do insn->n samplesThe `insn_rw_emulate_bits()` function is used as a default handler for`INSN_READ` instructions for subdevices that have a handler for`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a defaulthandler for `INSN_WRITE` instructions for subdevices that have a handlerfor `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the`INSN_READ` or `INSN_WRITE` instruction handling with a constructed`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`instructions are supposed to be able read or write multiple samples,indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currentlyonly handles a single sample. For `INSN_READ`, the comedi core willcopy `insn->n` samples back to user-space. (That triggered KASANkernel-infoleak errors when `insn->n` was greater than 1, but that isbeing fixed more generally elsewhere in the comedi core.)Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or returnan error, to conform to the general expectation for `INSN_READ` and`INSN_WRITE` handlers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: fix panic due to PSLVERRWhen the PSLVERR_RESP_EN parameter is set to 1, the device generatesan error response if an attempt is made to read an empty RBR (ReceiveBuffer Register) while the FIFO is enabled.In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokesdw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latterfunction enables the FIFO via serial_out(p, UART_FCR, p->fcr).Execution proceeds to the serial_port_in(port, UART_RX).This satisfies the PSLVERR trigger condition.When another CPU (e.g., using printk()) is accessing the UART (UARTis busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enterdw8250_force_idle().Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lockto fix this issue.Panic backtrace:[ 0.442336] Oops - unknown exception [#1][ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e...[ 0.442416] console_on_rootfs+0x26/0x70
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/hisilicon/hibmc: fix the hibmc loaded failed bugWhen hibmc loaded failed, the driver use hibmc_unload to free theresource, but the mutexes in mode.config are not init, which willaccess an NULL pointer. Just change goto statement to return, becausehibnc_hw_init() doesn't need to free anything.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error pathDuring tests of another unrelated patch I was able to trigger thiserror: Objects remaining on __kmem_cache_shutdown()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_freeThe previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly atremoval") patched a UAF issue caused by the error timer.However, because the error timer kill added in this patch occurs after theendpoint delete, a race condition to UAF still occurs, albeit rarely.Additionally, since kill-cleanup for urb is also missing, freed memory canbe accessed in interrupt context related to urb, which can cause UAF.Therefore, to prevent this, error timer and urb must be killed beforefreeing the heap memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/ksm: fix flag-dropping behavior in ksm_madvisesyzkaller discovered the following crash: (kernel BUG)[ 44.607039] ------------[ cut here ]------------[ 44.607422] kernel BUG at mm/userfaultfd.c:2067![ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460[ 44.617726] Call Trace:[ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0[ 44.620976] __fput+0x3f9/0xb60[ 44.621240] fput_close_sync+0x110/0x210[ 44.622222] __x64_sys_close+0x8f/0x120[ 44.622530] do_syscall_64+0x5b/0x2f0[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 44.623244] RIP: 0033:0x7f365bb3f227Kernel panics because it detects UFFD inconsistency duringuserfaultfd_release_all(). Specifically, a VMA which has a valid pointerto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.The inconsistency is caused in ksm_madvise(): when user calls madvise()with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,it accidentally clears all flags stored in the upper 32 bits ofvma->vm_flags.Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int andint are 32-bit wide. This setup causes the following mishap during the &=~VM_MERGEABLE assignment.VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is thenpromoted to unsigned long before the & operation. This promotion fillsupper 32 bits with leading 0s, as we're doing unsigned conversion (andeven for a signed conversion, this wouldn't help as the leading bit is 0).& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffffinstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clearsthe upper 32-bits of its value.Fix it by changing `VM_MERGEABLE` constant to unsigned long, using theBIT() macro.Note: other VM_* flags are not affected: This only happens to theVM_MERGEABLE flag, as the other VM_* flags are all constants of type intand after ~ operation, they end up with leading 1 and are thus convertedto unsigned long with leading 1s.Note 2:After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this isno longer a kernel BUG, but a WARNING at the same place:[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067but the root-cause (flag-drop) remains the same.[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Let userspace take care of interrupt maskRemove the logic to set interrupt mask by default in uio_hv_genericdriver as the interrupt mask value is supposed to be controlledcompletely by the user space. If the mask bit gets changedby the driver, concurrently with user mode operating on the ring,the mask bit may be set when it is supposed to be clear, and theuser-mode driver will miss an interrupt which will cause a hang.For eg- when the driver sets inbound ring buffer interrupt mask to 1,the host does not interrupt the guest on the UIO VMBus channel.However, setting the mask does not prevent the host from putting amessage in the inbound ring buffer. So let's assume that happens,the host puts a message into the ring buffer but does not interrupt.Subsequently, the user space code in the guest sets the inbound ringbuffer interrupt mask to 0, saying "Hey, I'm ready for interrupts".User space code then calls pread() to wait for an interrupt.Then one of two things happens:* The host never sends another message. So the pread() waits forever.* The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.This could be easily reproduced in hv_fcopy_uio_daemon if we delaysetting interrupt mask to 0.Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,there's a race condition. Once user space empties the inbound ringbuffer, but before user space sets interrupt_mask to 0, the host couldput another message in the ring buffer but it wouldn't interrupt.Then the next pread() would hang.Fix these by removing all instances where interrupt_mask is changed,while keeping the one in set_event() unchanged to enable userspacecontrol the interrupt mask by writing 0/1 to /dev/uioX.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in __pnet_find_base_ndev().syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),which was called during connect(). [0]smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passesdown to pnet_find_base_ndev(), where RTNL is held. Then, UAF happenedat __pnet_find_base_ndev() when the dev is first used.This means dev had already been freed before acquiring RTNL inpnet_find_base_ndev().While dev is going away, dst->dev could be swapped with blackhole_netdev,and the dev's refcnt by dst will be released.We must hold dev's refcnt before calling smc_pnet_find_ism_resource().Also, smc_pnet_find_roce_resource() has the same problem.Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.[0]:BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f47cbf8eba9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000bRBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bacflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pps: fix warning in pps_register_cdev when register device failSimilar to previous commit 2a934fdb01db ("media: v4l2-dev: fix errorhandling in __video_register_device()"), the release hook should be setbefore device_register(). Otherwise, when device_register() return errorand put_device() try to callback the release function, the below warningmay happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),pps_register_cdev() call device_create() to create pps->dev, which willinit dev->release to device_create_release(). Now the comment is outdated,just remove it.Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removedin pps_register_source() to avoid a double free in the failure case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe0e9fae16dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16dRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen hfsplus_uni2asc is called from hfsplus_listxattr,it actually passes in a struct hfsplus_attr_unistr*.The size of the corresponding structure is different from that of hfsplus_unistr,so the previous fix (94458781aee6) is insufficient.The pointer on the unicode buffer is still going beyond the allocated memory.This patch introduces two warpper functions hfsplus_uni2asc_xattr_str andhfsplus_uni2asc_str to process two unicode buffers,struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.When ustrlen value is bigger than the allocated memory size,the ustrlen value is limited to an safe size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()During mpt3sas_transport_port_remove(), messages were logged withdev_printk() against &mpt3sas_port->port->dev. At this point the SAStransport device may already be partially unregistered or freed, leadingto a crash when accessing its struct device.Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),guaranteed to remain valid until driver removal.[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0[83428.295844] PKRU: 55555554[83428.295846] Call Trace:[83428.295848] [83428.295850] _dev_printk+0x5c/0x80[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas][83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas][83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas][83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas][83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas][83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas][83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas][83428.295957] pci_device_remove+0x3b/0xb0[83428.295962] device_release_driver_internal+0x193/0x200[83428.295968] driver_detach+0x44/0x90[83428.295971] bus_remove_driver+0x69/0xf0[83428.295975] pci_unregister_driver+0x2a/0xb0[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas][83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296000] ? __x64_sys_getdents64+0x9a/0x110[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296009] ? syscall_trace_enter+0xf6/0x1b0[83428.296014] do_syscall_64+0x7b/0x2c0[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: berlin: Fix wrong register in suspend/resumeThe 'enable' register should be BERLIN_PWM_EN rather thanBERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, therewill be cpu exception then kernel panic during suspend/resume.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()Unlike other strings in the ext4 superblock, we rely on tune2fs tomake sure s_mount_opts is NUL terminated. Hardenparse_apply_sb_mount_options() by treating s_mount_opts as a potential__nonstring.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: reject negative file sizes in squashfs_read_inode()Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size.This commit checks for a negative file size and returns EINVAL.[phillip@squashfs.org.uk: only need to check 64 bit quantity]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid potential out-of-bounds in btrfs_encode_fh()The function btrfs_encode_fh() does not properly account for the threecases it handles.Before writing to the file handle (fh), the function only returns to theuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) orBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).However, when a parent exists and the root ID of the parent and theinode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT(10 dwords, 40 bytes).If *max_len is not large enough, this write goes out of bounds becauseBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater thanBTRFS_FID_SIZE_CONNECTABLE originally returned.This results in an 8-byte out-of-bounds write atfid->parent_root_objectid = parent_root_id.A previous attempt to fix this issue was made but was lost.https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/Although this issue does not seem to be easily triggerable, it is apotential memory corruption bug that should be fixed. This patchresolves the issue by ensuring the function returns the appropriate sizefor all three cases and validates that *max_len is large enough beforewriting any data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()The syzbot reported issue in __hfsplus_ext_cache_extent():[ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990[ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990[ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0[ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0[ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0[ 70.196959][ T9350] cont_write_begin+0x1000/0x1950[ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130[ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060[ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460[ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0[ 70.199393][ T9350] vfs_write+0xb0f/0x14e0[ 70.199771][ T9350] ksys_write+0x23e/0x490[ 70.200149][ T9350] __x64_sys_write+0x97/0xf0[ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0[ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0[ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.202054][ T9350][ 70.202279][ T9350] Uninit was created at:[ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80[ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0[ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0[ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0[ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0[ 70.205074][ T9350] cont_write_begin+0x1000/0x1950[ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130[ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060[ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460[ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0[ 70.207552][ T9350] vfs_write+0xb0f/0x14e0[ 70.207961][ T9350] ksys_write+0x23e/0x490[ 70.208375][ T9350] __x64_sys_write+0x97/0xf0[ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0[ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0[ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.210230][ T9350][ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5[ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.212115][ T9350] =====================================================[ 70.212734][ T9350] Disabling lock debugging due to kernel taint[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ...[ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5[ 70.214679][ T9350] Tainted: [B]=BAD_PAGE[ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.215999][ T9350] Call Trace:[ 70.216309][ T9350] [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0[ 70.217025][ T9350] dump_stack+0x1e/0x30[ 70.217421][ T9350] panic+0x502/0xca0[ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0[ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel:[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0set ...[ 70.221254][ T9350] ? __msan_warning+0x96/0x120[ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990[ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0[ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0[ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0[ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950[ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130[ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060[ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460[ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0[ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0[ 70.228997][ T9350] ? ksys_write+0x23e/0x490---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never addedIn commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), Imissed the case where state creation fails between fullinitialization (->init_state has been called) and being inserted onthe lists.In this situation, ->init_state has been called, so for IPcomptunnels, the fallback tunnel has been created and added onto thelists, but the user state never gets added, because we fail beforethat. The user state doesn't go through __xfrm_state_delete, so wedon't call xfrm_state_delete_tunnel for those states, and we end upleaking the FB tunnel.There are several codepaths affected by this: the add/update paths, inboth net/key and xfrm, and the migrate code (xfrm_migrate,xfrm_state_migrate). A "proper" rollback of the init_state work wouldprobably be doable in the add/update code, but for migrate it getsmore complicated as multiple states may be involved.At some point, the new (not-inserted) state will be destroyed, so callxfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most stateswill have their fallback tunnel cleaned up during __xfrm_state_delete,which solves the issue that b441cf3f8c4b (and other patches before it)aimed at. All states (including FB tunnels) will be removed from thelists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential overflow of PCM transfer bufferThe PCM stream data in USB-audio driver is transferred over USB URBpacket buffers, and each packet size is determined dynamically. Thepacket sizes are limited by some factors such as wMaxPacketSize USBdescriptor. OTOH, in the current code, the actually used packet sizesare determined only by the rate and the PPS, which may be bigger thanthe size limit above. This results in a buffer overflow, as reportedby syzbot.Basically when the limit is smaller than the calculated packet size,it implies that something is wrong, most likely a weird USBdescriptor. So the best option would be just to return an error atthe parameter setup time before doing any further operations.This patch introduces such a sanity check, and returns -EINVAL whenthe packet size is greater than maxpacksize. The comparison withep->packsize[1] alone should suffice since it's always equal orgreater than ep->packsize[0].
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_baddIn snd_usb_create_streams(), for UAC version 3 devices, the InterfaceAssociation Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If thiscall fails, a fallback routine attempts to obtain the IAD from the nextinterface and sets a BADD profile. However, snd_usb_mixer_controls_badd()assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,without performing a NULL check. This can lead to a NULL pointerdereference when usb_ifnum_to_if() fails to find the interface descriptor.This patch adds a NULL pointer check after calling usb_ifnum_to_if() insnd_usb_mixer_controls_badd() to prevent the dereference.This issue was discovered by syzkaller, which triggered the bug by sendinga crafted USB device descriptor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZEThis data originates from userspace and is used in buffer offsetcalculations which could potentially overflow causing an out-of-boundsaccess.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-boundsAdd bounds checking to prevent writes past framebuffer boundaries whenrendering text near screen edges. Return early if the Y position is off-screenand clip image height to screen boundary. Break from the rendering loop if theX position is off-screen. When clipping image width to fit the screen, updatethe character count to match the clipped width to prevent buffer sizemismatches.Without the character count update, bit_putcs_aligned and bit_putcs_unalignedreceive mismatched parameters where the buffer is allocated for the clippedwidth but cnt reflects the original larger count, causing out-of-bounds writes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bcsp: receive data only if registeredCurrently, bcsp_recv() can be called even when the BCSP protocol has notbeen registered. This leads to a NULL pointer dereference, as shown inthe following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fTo prevent this, ensure that the HCI_UART_REGISTERED flag is set beforeprocessing received data. If the protocol is not registered, return-EUNATCH.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix crash while sending Action Frames in standalone AP ModeCurrently, whenever there is a need to transmit an Action frame,the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR tofirmware. The P2P interfaces were available when wpa_supplicant is managingthe wlan interface.However, the P2P interfaces are not created/initialized when only hostapdis managing the wlan interface. And if hostapd receives an ANQP Query REQAction frame even from an un-associated STA, the brcmfmac driver triesto use an uninitialized P2P vif pointer for sending the IOVAR to firmware.This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)Fix this, by always using the vif corresponding to the wdev on which theAction frame Transmission request was initiated by the userspace. This way,even if P2P vif is not available, the IOVAR is sent to firmware on AP vifand the ANQP Query RESP Action frame is transmitted without crashing thedriver.Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()to brcmf_p2p_attach(). Because the former function would not get executedwhen only hostapd is managing wlan interface, and it is not safe to doreinit_completion() later in brcmf_p2p_tx_action_frame(), without any priorinit_completion().And in the brcmf_p2p_tx_action_frame() function, the condition check forP2P Presence response frame is not needed, since the wpa_supplicant isproperly sending the P2P Presense Response frame on the P2P-GO vif insteadof the P2P-Device vif.[Cc stable]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: validate record offset in hfsplus_bmap_allochfsplus_bmap_alloc can trigger a crash if arecord offset or length is larger than node_size[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0[ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183[ 15.265949][ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)[ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 15.266167] Call Trace:[ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70[ 15.266173] print_report+0xd0/0x660[ 15.266181] kasan_report+0xce/0x100[ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0[ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0[ 15.266217] hfsplus_brec_insert+0x870/0xb00[ 15.266222] __hfsplus_ext_write_extent+0x428/0x570[ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910[ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200[ 15.266233] hfsplus_file_extend+0x5a7/0x1000[ 15.266237] hfsplus_get_block+0x12b/0x8c0[ 15.266238] __block_write_begin_int+0x36b/0x12c0[ 15.266251] block_write_begin+0x77/0x110[ 15.266252] cont_write_begin+0x428/0x720[ 15.266259] hfsplus_write_begin+0x51/0x100[ 15.266262] cont_write_begin+0x272/0x720[ 15.266270] hfsplus_write_begin+0x51/0x100[ 15.266274] generic_perform_write+0x321/0x750[ 15.266285] generic_file_write_iter+0xc3/0x310[ 15.266289] __kernel_write_iter+0x2fd/0x800[ 15.266296] dump_user_range+0x2ea/0x910[ 15.266301] elf_core_dump+0x2a94/0x2ed0[ 15.266320] vfs_coredump+0x1d85/0x45e0[ 15.266349] get_signal+0x12e3/0x1990[ 15.266357] arch_do_signal_or_restart+0x89/0x580[ 15.266362] irqentry_exit_to_user_mode+0xab/0x110[ 15.266364] asm_exc_page_fault+0x26/0x30[ 15.266366] RIP: 0033:0x41bd35[ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f[ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283[ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000[ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100[ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000[ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000[ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000[ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this functionfirst retrieves the bitmap from header node and map node using node->pagetogether with the offset and length from hfs_brec_lenoff```len = hfs_brec_lenoff(node, 2, &off16);off = off16;off += node->page_offset;pagep = node->page + (off >> PAGE_SHIFT);data = kmap_local_page(*pagep);```However, if the retrieved offset or length is invalid(i.e. exceedsnode_size), the code may end up accessing pages outside the allocatedrange for this node.This patch adds proper validation of both offset and length before use,preventing out-of-bounds page access. Move is_bnode_offset_valid andcheck_and_correct_requested_length to hfsplus_fs.h, as they may berequired by other functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()The syzbot reported issue in hfsplus_delete_cat():[ 70.682285][ T9333] =====================================================[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810[ 70.685447][ T9333] do_rmdir+0x964/0xea0[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.687646][ T9333][ 70.687856][ T9333] Uninit was stored to memory at:[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.692773][ T9333][ 70.692990][ T9333] Uninit was stored to memory at:[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700[ 70.694911][ T9333] mount_bdev+0x37b/0x530[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0[ 70.696588][ T9333] do_new_mount+0x73e/0x1630[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0[ 70.697425][ T9333] __se_sys_mount+0x733/0x830[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.699730][ T9333][ 70.699946][ T9333] Uninit was created at:[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0[ 70.701774][ T9333] allocate_slab+0x30e/0x1390[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0[ 70.703598][ T9333] alloc_inode+0x82/0x490[ 70.703984][ T9333] iget_locked+0x22e/0x1320[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700[ 70.705776][ T9333] mount_bdev+0x37b/0x530[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0[ 70.707444][ T9333] do_new_mount+0x73e/0x1630[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0[ 70.708270][ T9333] __se_sys_mount+0x733/0x830[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.710611][ T9333][ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.712490][ T9333] =====================================================[ 70.713085][ T9333] Disabling lock debugging due to kernel taint[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...[ 70.714159][ T9333] ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencingTheoretically it's an oopsable race, but I don't believe one can manageto hit it on real hardware; might become doable on a KVM, but it stillwon't be easy to attack.Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call ofput_unaligned_be64(), we can put that under ->d_lock and be done with that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixupRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.This can trigger kernel panics on ARM64 when xfrm or other subsystemsaccess the offset due to strict alignment checks.Initialize the MAC header to prevent such crashes.This can trigger kernel panics on ARM when running IPsec over theqmimux0 interface.Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: multiq3: sanitize config options in multiq3_attach()Syzbot identified an issue [1] in multiq3_attach() that induces atask timeout due to open() or COMEDI_DEVCONFIG ioctl operations,specifically, in the case of multiq3 driver.This problem arose when syzkaller managed to craft weird configurationoptions used to specify the number of channels in encoder subdevice.If a particularly great number is passed to s->n_chan inmultiq3_attach() via it->options[2], then multiple calls tomultiq3_encoder_reset() at the end of driver-specific attach() methodwill be running for minutes, thus blocking tasks and affected devicesas well.While this issue is most likely not too dangerous for real-lifedevices, it still makes sense to sanitize configuration inputs. Enablea sensible limit on the number of encoder chips (4 chips max, eachwith 2 channels) to stop this behaviour from manifesting.[1] Syzbot crash:INFO: task syz.2.19:6067 blocked for more than 143 seconds....Call Trace: context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call pathsThis patch addresses a race condition caused by unsynchronizedexecution of multiple call paths invoking `dwc3_remove_requests()`,leading to premature freeing of USB requests and subsequent crashes.Three distinct execution paths interact with `dwc3_remove_requests()`:Path 1:Triggered via `dwc3_gadget_reset_interrupt()` during USB resethandling. The call stack includes:- `dwc3_ep0_reset_state()`- `dwc3_ep0_stall_and_restart()`- `dwc3_ep0_out_start()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 2:Also initiated from `dwc3_gadget_reset_interrupt()`, but through`dwc3_stop_active_transfers()`. The call stack includes:- `dwc3_stop_active_transfers()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 3:Occurs independently during `adb root` execution, which triggersUSB function unbind and bind operations. The sequence includes:- `gserial_disconnect()`- `usb_ep_disable()`- `dwc3_gadget_ep_disable()`- `dwc3_remove_requests()` with `-ESHUTDOWN` statusPath 3 operates asynchronously and lacks synchronization with Paths1 and 2. When Path 3 completes, it disables endpoints and frees 'out'requests. If Paths 1 or 2 are still processing these requests,accessing freed memory leads to a crash due to use-after-free conditions.To fix this added check for request completion and skip processingif already completed and added the request status for ep0 while queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: intel: punit_ipc: fix memory corruptionThis passes the address of the pointer "&punit_ipcdev" when the intentwas to pass the pointer itself "punit_ipcdev" (without the ampersand).This means that the: complete(&ipcdev->cmd_complete);in intel_punit_ioc() will write to a wrong memory address corrupting it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sock: Prevent race in socket write iter and sock bindThere is a potential race condition between sock bind and socket writeiter. bind may free the same cmd via mgmt_pending before write iter sendsthe cmd, just as syzbot reported in UAF[1].Here we use hci_dev_lock to synchronize the two, thereby avoiding theUAF mentioned in [1].[1]syzbot reported:BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316Read of size 8 at addr ffff888077164818 by task syz.0.17/5989Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Prevents free active keventThe root cause of this issue are:1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);put the kevent work in global workqueue. However, the kevent has not yetbeen scheduled when the usbnet device is unregistered. Therefore, executingfree_netdev() results in the "free active object (kevent)" error reportedhere.2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),if the usbnet device is up, ndo_stop() is executed to cancel the kevent.However, because the device is not up, ndo_stop() is not executed.The solution to this problem is to cancel the kevent before executingfree_netdev().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: bmc150: Fix irq assumption regressionThe code in bmc150-accel-core.c unconditionally callsbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,such as on the runtime PM resume path giving a kernelsplat like this if the device has no interrupts:Unable to handle kernel NULL pointer dereference at virtual address 00000001 when readPC is at bmc150_accel_set_interrupt+0x98/0x194LR is at __pm_runtime_resume+0x5c/0x64(...)Call trace:bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc__iio_update_buffers from enable_store+0x84/0xc8enable_store from kernfs_fop_write_iter+0x154/0x1b4This bug seems to have been in the driver since the beginning,but it only manifests recently, I do not know why.Store the IRQ number in the state struct, as this is a commonpattern in other drivers, then use this to determine if we haveIRQ support or not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexregulator_supply_alias_list was accessed without any locking inregulator_supply_alias(), regulator_register_supply_alias(), andregulator_unregister_supply_alias(). Concurrent registration,unregistration and lookups can race, leading to:1 use-after-free if an alias entry is removed while being read,2 duplicate entries when two threads register the same alias,3 inconsistent alias mappings observed by consumers.Protect all traversals, insertions and deletions onregulator_supply_alias_list with the existing regulator_list_mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()The rtl8187_rx_cb() calculates the rx descriptor header addressby subtracting its size from the skb tail pointer.However, it does not validate if the received packet(skb->len from urb->actual_length) is large enough to contain thisheader.If a truncated packet is received, this will lead to a bufferunderflow, reading memory before the start of the skb data area,and causing a kernel panic.Add length checks for both rtl8187 and rtl8187b descriptor headersbefore attempting to access them, dropping the packet cleanly if thecheck fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_idUse check_add_overflow() to guard against potential integer overflowswhen adding the binary blob lengths and the size of an asymmetric_key_idstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents apossible buffer overflow when copying data from potentially maliciousX.509 certificate fields that can be arbitrarily large, such as ASN.1INTEGER serial numbers, issuer names, etc.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: Handle error code returned by ima_filter_rule_match()In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due tothe rule being NULL, the function incorrectly skips the 'if (!rc)' checkand sets 'result = true'. The LSM rule is considered a match, causingextra files to be measured by IMA.This issue can be reproduced in the following scenario:After unloading the SELinux policy module via 'semodule -d', if an IMAmeasurement is triggered before ima_lsm_rules is updated,in ima_match_rules(), the first call to ima_filter_rule_match() returns-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. Inima_lsm_copy_rule(), since the SELinux module has been removed, the rulebecomes NULL, and the second call to ima_filter_rule_match() returns-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that errorcodes like -ENOENT do not bypass the check and accidentally result in asuccessful match.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vgem-fence: Fix potential deadlock on releaseA timer that expires a vgem fence automatically in 10 seconds is nowreleased with timer_delete_sync() from fence->ops.release() called on lastdma_fence_put(). In some scenarios, it can run in IRQ context, which isnot safe unless TIMER_IRQSAFE is used. One potentially risky scenario wasdemonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, whileworking on new IGT subtests syncobj_timeline@stress-* as user spacereplacements of some problematic test cases of a dma-fence-chain selftest[1].[117.004338] ================================[117.004340] WARNING: inconsistent lock state[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U[117.004346] --------------------------------[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190[117.004361] {HARDIRQ-ON-W} state was registered at:[117.004363] lock_acquire+0xc4/0x2e0[117.004366] call_timer_fn+0x80/0x2a0[117.004368] __run_timers+0x231/0x310[117.004370] run_timer_softirq+0x76/0xe0[117.004372] handle_softirqs+0xd4/0x4d0[117.004375] __irq_exit_rcu+0x13f/0x160[117.004377] irq_exit_rcu+0xe/0x20[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20[117.004385] cpuidle_enter_state+0x12b/0x8a0[117.004388] cpuidle_enter+0x2e/0x50[117.004393] call_cpuidle+0x22/0x60[117.004395] do_idle+0x1fd/0x260[117.004398] cpu_startup_entry+0x29/0x30[117.004401] start_secondary+0x12d/0x160[117.004404] common_startup_64+0x13e/0x141[117.004407] irq event stamp: 2282669[117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80[117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0[117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18[117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160[117.004426]other info that might help us debug this:[117.004429] Possible unsafe locking scenario:[117.004432] CPU0[117.004433] ----[117.004434] lock((&fence->timer));[117.004436] [117.004438] lock((&fence->timer));[117.004440] *** DEADLOCK ***[117.004443] 1 lock held by swapper/0/0:[117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0[117.004450]stack backtrace:[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023[117.004456] Call Trace:[117.004456] [117.004457] dump_stack_lvl+0x91/0xf0[117.004460] dump_stack+0x10/0x20[117.004461] print_usage_bug.part.0+0x260/0x360[117.004463] mark_lock+0x76e/0x9c0[117.004465] ? register_lock_class+0x48/0x4a0[117.004467] __lock_acquire+0xbc3/0x2860[117.004469] lock_acquire+0xc4/0x2e0[117.004470] ? __timer_delete_sync+0x4b/0x190[117.004472] ? __timer_delete_sync+0x4b/0x190[117.004473] __timer_delete_sync+0x68/0x190[117.004474] ? __timer_delete_sync+0x4b/0x190[117.004475] timer_delete_sync+0x10/0x20[117.004476] vgem_fence_release+0x19/0x30 [vgem][117.004478] dma_fence_release+0xc1/0x3b0[117.004480] ? dma_fence_release+0xa1/0x3b0[117.004481] dma_fence_chain_release+0xe7/0x130[117.004483] dma_fence_release+0xc1/0x3b0[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80[117.004485] dma_fence_chain_irq_work+0x59/0x80[117.004487] irq_work_single+0x75/0xa0[117.004490] irq_work_r---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix kernel BUG in ocfs2_find_victim_chainsyzbot reported a kernel BUG in ocfs2_find_victim_chain() because the`cl_next_free_rec` field of the allocation chain list (next free slot inthe chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)condition in ocfs2_find_victim_chain() and panicking the kernel.To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),just before calling ocfs2_find_victim_chain(), the code block in it beingexecuted when either of the following conditions is true:1. `cl_next_free_rec` is equal to 0, indicating that there are no freechains in the allocation chain list2. `cl_next_free_rec` is greater than `cl_count` (the total number ofchains in the allocation chain list)Either of them being true is indicative of the fact that there are nochains left for usage.This is addressed using ocfs2_error(), which printsthe error log for debugging purposes, rather than panicking the kernel.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-mixer: us16x08: validate meter packet indicesget_meter_levels_from_urb() parses the 64-byte meter packets sent bythe device and fills the per-channel arrays meter_level[],comp_level[] and master_level[] in struct snd_us16x08_meter_store.Currently the function derives the channel index directly from themeter packet (MUB2(meter_urb, s) - 1) and uses it to index thosearrays without validating the range. If the packet contains anegative or out-of-range channel number, the driver may write pastthe end of these arrays.Introduce a local channel variable and validate it before updating thearrays. We reject negative indices, limit meter_level[] andcomp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]updates with ARRAY_SIZE(master_level).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix memory leak in nr_sendmsg()syzbot reported a memory leak [1].When function sock_alloc_send_skb() return NULL in nr_output(), theoriginal skb is not freed, which was allocated in nr_sendmsg(). Fix thisby freeing it before return.[1]BUG: memory leakunreferenced object 0xffff888129f35500 (size 240): comm "syz.0.17", pid 6119, jiffies 4294944652 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(.... backtrace (crc 1456a3e4): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4983 [inline] slab_alloc_node mm/slub.c:5288 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671 sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965 sock_alloc_send_skb include/net/sock.h:1859 [inline] nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x293/0x2a0 net/socket.c:1195 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0x143/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()rlen value is a user-controlled value, but dtv5100_i2c_msg() does notcheck the size of the rlen value. Therefore, if it is set to a valuelarger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.Therefore, we need to add proper range checking to prevent this vuln.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: invalidate dentry cache on failed whiteout creationF2FS can mount filesystems with corrupted directory depth values thatget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUToperations are performed on such directories, f2fs_rename performsdirectory modifications (updating target entry and deleting sourceentry) before attempting to add the whiteout entry via f2fs_add_link.If f2fs_add_link fails due to the corrupted directory structure, thefunction returns an error to VFS, but the partial directorymodifications have already been committed to disk. VFS assumes theentire rename operation failed and does not update the dentry cache,leaving stale mappings.In the error path, VFS does not call d_move() to update the dentrycache. This results in new_dentry still pointing to the old inode(new_inode) which has already had its i_nlink decremented to zero.The stale cache causes subsequent operations to incorrectly referencethe freed inode.This causes subsequent operations to use cached dentry information thatno longer matches the on-disk state. When a second rename targets thesame entry, VFS attempts to decrement i_nlink on the stale inode, whichmay already have i_nlink=0, triggering a WARNING in drop_nlink().Example sequence:1. First rename (RENAME_WHITEOUT): file2 -> file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 -> inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)2. Second rename: file3 -> file1 - VFS uses stale cache: file1 -> inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()Fix this by explicitly invalidating old_dentry and new_dentry whenf2fs_add_link fails during whiteout creation. This forces VFS torefresh from disk on subsequent operations, ensuring cache consistencyeven when the rename partially succeeds.Reproducer:1. Mount F2FS image with corrupted i_current_depth2. renameat2(file2, file1, RENAME_WHITEOUT)3. renameat2(file3, file1, 0)4. System triggers WARNING in drop_nlink()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_writeA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()due to lock ordering inversion between device_lock and rfkill_global_mutex.The problematic lock order is:Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lockThread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutexThis creates a classic ABBA deadlock scenario.Fix this by moving rfkill_unregister() and rfkill_destroy() outside thedevice_lock critical section. Store the rfkill pointer in a local variablebefore releasing the lock, then call rfkill_unregister() after releasingdevice_lock.This change is safe because rfkill_fop_write() holds rfkill_global_mutexwhile calling the rfkill callbacks, and rfkill_unregister() also acquiresrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() willwait for any ongoing callback to complete before proceeding, anddevice_del() is only called after rfkill_unregister() returns, preventingany use-after-free.The similar lock ordering in nfc_register_device() (device_lock ->rfkill_global_mutex via rfkill_register) is safe because duringregistration the device is not yet in rfkill_list, so no concurrentrfkill operations can occur on this device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: revert use of devm_kzalloc in btusbThis reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc inbtusb.c file").In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. Thisties the lifetime of all the btusb data to the binding of a driver toone interface, INTF. In a driver that binds to other interfaces, ISOCand DIAG, this is an accident waiting to happen.The issue is revealed in btusb_disconnect(), where callingusb_driver_release_interface(&btusb_driver, data->intf) will have devmfree the data that is also being used by the other interfaces of thedriver that may not be released yet.To fix this, revert the use of devm and go back to freeing memoryexplicitly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Do not use req->iv after crypto_aead_encryptAs soon as crypto_aead_encrypt is called, the underlying requestmay be freed by an asynchronous completion. Thus dereferencingreq->iv after it returns is invalid.Instead of checking req->iv against info, create a new variableunaligned_info and use it for that purpose instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()It's possible for cp_read() and hdmi_read() to return -EIO. Thosevalues are further used as indexes for accessing arrays.Fix that by checking return values where it's needed.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: disable recursive forward error correctionThere are two problems with the recursive correction:1. It may cause denial-of-service. In fec_read_bufs, there is a loop thathas 253 iterations. For each iteration, we may call verity_hash_for_blockrecursively. There is a limit of 4 nested recursions - that means thatthere may be at most 253^4 (4 billion) iterations. Red Hat QE teamactually created an image that pushes dm-verity to this limit - and thisimage just makes the udev-worker process get stuck in the 'D' state.2. It doesn't work. In fec_read_bufs we store data into the variable"fio->bufs", but fio bufs is shared between recursive invocations, if"verity_hash_for_block" invoked correction recursively, it wouldoverwrite partially filled fio->bufs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: tegra-adma: Fix use-after-freeA use-after-free bug exists in the Tegra ADMA driver when audio streamsare terminated, particularly during XRUN conditions. The issue occurswhen the DMA buffer is freed by tegra_adma_terminate_all() before thevchan completion tasklet finishes accessing it.The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memorySince tasklets can execute at any time after being scheduled, there isno guarantee that the buffer will remain valid when vchan_complete()runs.Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors.Crash logs:[ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0[ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0[ 337.427562] Call trace:[ 337.427564] dump_backtrace+0x0/0x320[ 337.427571] show_stack+0x20/0x30[ 337.427575] dump_stack_lvl+0x68/0x84[ 337.427584] print_address_description.constprop.0+0x74/0x2b8[ 337.427590] kasan_report+0x1f4/0x210[ 337.427598] __asan_load8+0xa0/0xd0[ 337.427603] vchan_complete+0x124/0x3b0[ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0[ 337.427617] tasklet_action+0x30/0x40[ 337.427623] __do_softirq+0x1a0/0x5c4[ 337.427628] irq_exit+0x110/0x140[ 337.427633] handle_domain_irq+0xa4/0xe0[ 337.427640] gic_handle_irq+0x64/0x160[ 337.427644] call_on_irq_stack+0x20/0x4c[ 337.427649] do_interrupt_handler+0x7c/0x90[ 337.427654] el1_interrupt+0x30/0x80[ 337.427659] el1h_64_irq_handler+0x18/0x30[ 337.427663] el1h_64_irq+0x7c/0x80[ 337.427667] cpuidle_enter_state+0xe4/0x540[ 337.427674] cpuidle_enter+0x54/0x80[ 337.427679] do_idle+0x2e0/0x380[ 337.427685] cpu_startup_entry+0x2c/0x70[ 337.427690] rest_init+0x114/0x130[ 337.427695] arch_call_rest_init+0x18/0x24[ 337.427702] start_kernel+0x380/0x3b4[ 337.427706] __primary_switched+0xc0/0xc8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: dma-crossbar: fix device leak on am335x route allocationMake sure to drop the reference taken when looking up the crossbarplatform device during am335x route allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: lpc18xx-dmamux: fix device leak on route allocationMake sure to drop the reference taken when looking up the DMA muxplatform device during route allocation.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: When extracting a tar archive pip may not check symbolic links point into the extraction directory if the tarfile module doesn't implement PEP 706.Note that upgrading pip to a "fixed" version for this vulnerability doesn't fix all known vulnerabilities that are remediated by using a Python version that implements PEP 706.Note that this is a vulnerability in pip's fallback implementation of tar extraction for Python versions that don't implement PEP 706and therefore are not secure to all vulnerabilities in the Python 'tarfile' module. If you're using a Python version that implements PEP 706then pip doesn't use the "vulnerable" fallback code.Mitigations include upgrading to a version of pip that includes the fix, upgrading to a Python version that implements PEP 706 (Python >=3.9.17, >=3.10.12, >=3.11.4, or >=3.12),applying the linked patch, or inspecting source distributions (sdists) before installation as is already a best-practice.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.90.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: avoid kernel-infoleak from struct iw_pointstruct iw_point has a 32bit hole on 64bit arches.struct iw_point { void __user *pointer; /* Pointer to the data (in user space) */ __u16 length; /* number of fields or size in bytes */ __u16 flags; /* Optional params */};Make sure to zero the structure to avoid disclosing 32bits of kernel datato user space.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: provide locking for v4_end_graceWriting to v4_end_grace can race with server shutdown and result inmemory being accessed after it was freed - reclaim_str_hashtbl inparticularly.We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that isheld while client_tracking_op->init() is called and that can wait foran upcall to nfsdcltrack which can write to v4_end_grace, resulting in adeadlock.nfsd4_end_grace() is also called by the landromat work queue and thisdoesn't require locking as server shutdown will stop the work and waitfor it before freeing anything that nfsd4_end_grace() might access.However, we must be sure that writing to v4_end_grace doesn't restartthe work item after shutdown has already waited for it. For this weadd a new flag protected with nn->client_lock. It is set only while itis safe to make client tracking calls, and v4_end_grace only scheduleswork while the flag is set with the spinlock held.So this patch adds a nfsd_net field "client_tracking_active" which isset as described. Another field "grace_end_forced", is set whenv4_end_grace is written. After this is set, and providingclient_tracking_active is set, the laundromat is scheduled.This "grace_end_forced" field bypasses other checks for whether thegrace period has finished.This resolves a race which can result in use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make free_choose_arg_map() resilient to partial allocationfree_choose_arg_map() may dereference a NULL pointer if its caller failsafter a partial allocation.For example, in decode_choose_args(), if allocation of arg_map->argsfails, execution jumps to the fail label and free_choose_arg_map() iscalled. Since arg_map->size is updated to a non-zero value before memoryallocation, free_choose_arg_map() will iterate over arg_map->args anddereference a NULL pointer.To prevent this potential NULL pointer dereference and makefree_choose_arg_map() more resilient, add checks for pointers beforeiterating.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovecCommit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")added ttag bounds checking and data_offsetvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validatewhether the command's data structures (cmd->req.sg and cmd->iov) havebeen properly initialized before processing H2C_DATA PDUs.The nvmet_tcp_build_pdu_iovec() function dereferences these pointerswithout NULL checks. This can be triggered by sending H2C_DATA PDUimmediately after the ICREQ/ICRESP handshake, beforesending a CONNECT command or NVMe write command.Attack vectors that trigger NULL pointer dereferences:1. H2C_DATA PDU sent before CONNECT -> both pointers NULL2. H2C_DATA PDU for READ command -> cmd->req.sg allocated, cmd->iov NULL3. H2C_DATA PDU for uninitialized command slot -> both pointers NULLThe fix validates both cmd->req.sg and cmd->iov before callingnvmet_tcp_build_pdu_iovec(). Both checks are required because:- Uninitialized commands: both NULL- READ commands: cmd->req.sg allocated, cmd->iov NULL- WRITE commands: both allocated
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_gre: make ipgre_header() robustAnalog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")Over the years, syzbot found many ways to crash the kernelin ipgre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ipgre device.[1]skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 !Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- expat > 0-0 (version in image is 2.7.1-21.46.1).
-
Description: Directory traversal vulnerability in the (1) extract and (2) extractall functions in the tarfile module in Python allows user-assisted remote attackers to overwrite arbitrary files via a .. (dot dot) sequence in filenames in a TAR archive, a related issue to CVE-2001-1267.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.158.1).
-
Description: An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \r\n (specifically in the query string after a ? character) followed by an HTTP header or a Redis command. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-adv-systems-management-release >= 12-0 (version in image is 12-4.3.1).
- python3-Jinja2 > 0-0 (version in image is 2.8-22.11.1).
-
Description: An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers is calculated and truncated into a 32-bit integer. A pointer to partially controlled data can then be written out of bounds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libsqlite3-0 > 0-0 (version in image is 3.50.2-9.41.1).
-
Description: Python Software Foundation Python (CPython) version 2.7 contains a CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in shutil module (make_archive function) that can result in Denial of service, Information gain via injection of arbitrary files on the system or entire drive. This attack appear to be exploitable via Passage of unfiltered user input to the function. This vulnerability appears to have been fixed in after commit add531a1e55b0a739b0f42582f1c9747e5649ace.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The _bfd_XX_bfd_copy_private_bfd_data_common function in peXXigen.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, processes a negative Data Directory size with an unbounded loop that increases the value of (external_IMAGE_DEBUG_DIRECTORY) *edd so that the address exceeds its own memory region, resulting in an out-of-bounds memory write, as demonstrated by objcopy copying private info with _bfd_pex64_bfd_copy_private_bfd_data_common in pex64igen.c.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: It was found that the GnuTLS implementation of HMAC-SHA-256 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data using crafted packets.
Packages affected:
- libgnutls30 > 0-0 (version in image is 3.4.17-8.20.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of "Just in Time" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets.
Packages affected:
- libgnutls30 > 0-0 (version in image is 3.4.17-8.20.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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: In GNU Binutils 2.30, there's an integer overflow in the function load_specific_debug_section() in objdump.c, which results in `malloc()` with 0 size. A crafted ELF file allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The bfd_get_debug_link_info_1 function in opncls.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, has an unchecked strnlen operation. Remote attackers could leverage this vulnerability to cause a denial of service (segmentation fault) via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Remove device endpoints from bandwidth list when freeing the deviceEndpoints are normally deleted from the bandwidth list when they aredropped, before the virt device is freed.If xHC host is dying or being removed then the endpoints aren't droppedcleanly due to functions returning early to avoid interacting with anon-accessible host controller.So check and delete endpoints that are still on the bandwidth list whenfreeing the virt device.Solves a list_del corruption kernel crash when unbinding xhci-pci,caused by xhci_mem_cleanup() when it later tried to delete already freedendpoints from the bandwidth list.This only affects hosts that use software bandwidth checking, whichcurrenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix possible data races in gfs2_show_options()Some fields such as gt_logd_secs of the struct gfs2_tune are accessedwithout holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);And thus can cause data races when gfs2_show_options() and other functionssuch as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit;To fix these possible data races, the lock sdp->sd_tune.gt_spin isacquired before accessing the fields of gfs2_tune and released after theseaccesses.Further changes by Andreas:- Don't hold the spin lock over the seq_printf operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Do not swap cpu_buffer during resize processWhen ring_buffer_swap_cpu was called during resize process,the cpu buffer was swapped in the middle, resulting in incorrect state.Continuing to run in the wrong state will result in oops.This issue can be easily reproduced using the following two scripts:/tmp # cat test1.sh//#! /bin/shfor i in `seq 0 100000`do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo 5000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5done/tmp # cat test2.sh//#! /bin/shfor i in `seq 0 100000`do echo irqsoff > /sys/kernel/debug/tracing/current_tracer sleep 1 echo nop > /sys/kernel/debug/tracing/current_tracer sleep 1done/tmp # ./test1.sh &/tmp # ./test2.sh &A typical oops log is as follows, sometimes with other different oops logs.[ 231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8[ 231.713375] Modules linked in:[ 231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15[ 231.716750] Hardware name: linux,dummy-virt (DT)[ 231.718152] Workqueue: events update_pages_handler[ 231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 231.721171] pc : rb_update_pages+0x378/0x3f8[ 231.722212] lr : rb_update_pages+0x25c/0x3f8[ 231.723248] sp : ffff800082b9bd50[ 231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000[ 231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0[ 231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a[ 231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000[ 231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510[ 231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002[ 231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558[ 231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001[ 231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000[ 231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208[ 231.744196] Call trace:[ 231.744892] rb_update_pages+0x378/0x3f8[ 231.745893] update_pages_handler+0x1c/0x38[ 231.746893] process_one_work+0x1f0/0x468[ 231.747852] worker_thread+0x54/0x410[ 231.748737] kthread+0x124/0x138[ 231.749549] ret_from_fork+0x10/0x20[ 231.750434] ---[ end trace 0000000000000000 ]---[ 233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 233.721696] Mem abort info:[ 233.721935] ESR = 0x0000000096000004[ 233.722283] EC = 0x25: DABT (current EL), IL = 32 bits[ 233.722596] SET = 0, FnV = 0[ 233.722805] EA = 0, S1PTW = 0[ 233.723026] FSC = 0x04: level 0 translation fault[ 233.723458] Data abort info:[ 233.723734] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 233.724176] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 233.724589] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000[ 233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[ 233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 233.726720] Modules linked in:[ 233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15[ 233.727777] Hardware name: linux,dummy-virt (DT)[ 233.728225] Workqueue: events update_pages_handler[ 233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 233.729054] pc : rb_update_pages+0x1a8/0x3f8[ 233.729334] lr : rb_update_pages+0x154/0x3f8[ 233.729592] sp : ffff800082b9bd50[ 233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 00000000---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix out of bounds access in DCCP error handlerThere was a previous attempt to fix an out-of-bounds access in the DCCPerror handlers, but that fix assumed that the error handlers only wantto access the first 8 bytes of the DCCP header. Actually, they also lookat the DCCP sequence number, which is stored beyond 8 bytes, so anexplicit pskb_may_pull() is required.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix memleak of md threadIn raid10_run(), if setup_conf() succeed and raid10_run() failed beforesetting 'mddev->thread', then in the error path 'conf->thread' is notfreed.Fix the problem by setting 'mddev->thread' right after setup_conf().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libgnutls30 > 0-0 (version in image is 3.4.17-8.20.1).
-
Description: Allows modifying some file metadata (e.g. last modified) with filter="data" or file permissions (chmod) with filter="tar" of files outside the extraction directory.You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.158.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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.275.1).
-
Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.33.1).
-
Description: A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.33.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:
- curl > 0-0 (version in image is 8.0.1-11.108.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- curl > 0-0 (version in image is 8.0.1-11.108.1).
-
Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- curl > 0-0 (version in image is 8.0.1-11.108.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- curl > 0-0 (version in image is 8.0.1-11.108.1).
-
Description: The attack vector is a potential Denial of Service (DoS). The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In the CGI gem before 0.4.2 for Ruby, the CGI::Cookie.parse method in the CGI library contains a potential Denial of Service (DoS) vulnerability. The method does not impose any limit on the length of the raw cookie value it processes. This oversight can lead to excessive resource consumption when parsing extremely large cookies.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In the CGI gem before 0.4.2 for Ruby, a Regular Expression Denial of Service (ReDoS) vulnerability exists in the Util#escapeElement method.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In the URI gem before 1.0.3 for Ruby, the URI handling methods (URI.join, URI#merge, URI#+) have an inadvertent leakage of authentication credentials because userinfo is retained even after changing the host.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: initialize more fields in sctp_v6_from_sk()syzbot found that sin6_scope_id was not properly initialized,leading to undefined behavior.Clear sin6_scope_id and sin6_flowinfo.BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()The hfsplus_strcasecmp() logic can trigger the issue:[ 117.317703][ T9855] ==================================================================[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855[ 117.319577][ T9855][ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 117.319783][ T9855] Call Trace:[ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319842][ T9855] print_report+0x17e/0x7e0[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319876][ T9855] kasan_report+0x147/0x180[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0[ 117.320055][ T9855] lookup_slow+0x53/0x70[ 117.320065][ T9855] walk_component+0x2f0/0x430[ 117.320073][ T9855] path_lookupat+0x169/0x440[ 117.320081][ T9855] filename_lookup+0x212/0x590[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540[ 117.320112][ T9855] user_path_at+0x3a/0x60[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: bitblit: bound-check glyph index in bit_putcs*bit_putcs_aligned()/unaligned() derived the glyph pointer from thecharacter value masked by 0xff/0x1ff, which may exceed the actual font'sglyph count and read past the end of the built-in font array.Clamp the index to the actual glyph count before computing the address.This fixes a global out-of-bounds read reported by syzbot.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- docker > 0-0 (version in image is 28.4.0_ce-98.143.1).
-
Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- amazon-ssm-agent > 0-0 (version in image is 3.3.1611.0-4.39.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
-
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- docker > 0-0 (version in image is 28.4.0_ce-98.143.1).
-
Description: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- docker > 0-0 (version in image is 28.4.0_ce-98.143.1).
-
Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- openssh < 7.2p2-81.34.1 (version in image is 7.2p2-81.29.4).
-
Description: ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- openssh > 0-0 (version in image is 7.2p2-81.29.4).
-
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: Issue summary: When using the low-level OCB API directly with AES-NI or
other hardware-accelerated code paths, inputs whose length is not a multiple
of 16 bytes can leave the final partial block unencrypted and unauthenticated.
Impact summary: The trailing 1-15 bytes of a message may be exposed in
cleartext on encryption and are not covered by the authentication tag,
allowing an attacker to read or tamper with those bytes without detection.
The low-level OCB encrypt and decrypt routines in the hardware-accelerated
stream path process full 16-byte blocks but do not advance the input/output
pointers. The subsequent tail-handling code then operates on the original
base pointers, effectively reprocessing the beginning of the buffer while
leaving the actual trailing bytes unprocessed. The authentication checksum
also excludes the true tail bytes.
However, typical OpenSSL consumers using EVP are not affected because the
higher-level EVP and provider OCB implementations split inputs so that full
blocks and trailing partial blocks are processed in separate calls, avoiding
the problematic code path. Additionally, TLS does not use OCB ciphersuites.
The vulnerability only affects applications that call the low-level
CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with
non-block-aligned lengths in a single call on hardware-accelerated builds.
For these reasons the issue was assessed as Low severity.
The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected
by this issue, as OCB mode is not a FIPS-approved algorithm.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.
OpenSSL 1.0.2 is not affected by this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_1 < 1.1.1d-2.122.1 (version in image is 1.1.1d-2.119.1).
-
Description: Issue summary: A type confusion vulnerability exists in the TimeStamp Responseverification code where an ASN1_TYPE union member is accessed without firstvalidating the type, causing an invalid or NULL pointer dereference whenprocessing a malformed TimeStamp Response file.Impact summary: An application calling TS_RESP_verify_response() with amalformed TimeStamp Response can be caused to dereference an invalid orNULL pointer when reading, resulting in a Denial of Service.The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()access the signing cert attribute value without validating its type.When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memorythrough the ASN1_TYPE union, causing a crash.Exploiting this vulnerability requires an attacker to provide a malformedTimeStamp Response to an application that verifies timestamp responses. TheTimeStamp protocol (RFC 3161) is not widely used and the impact of theexploit is just a Denial of Service. For these reasons the issue wasassessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the TimeStamp Response implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_0_0 < 1.0.2p-3.103.1 (version in image is 1.0.2p-3.98.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glibc > 0-0 (version in image is 2.22-114.40.1).
-
Description: Issue summary: A type confusion vulnerability exists in the signatureverification of signed PKCS#7 data where an ASN1_TYPE union member isaccessed without first validating the type, causing an invalid or NULLpointer dereference when processing malformed PKCS#7 data.Impact summary: An application performing signature verification of PKCS#7data or calling directly the PKCS7_digest_from_attributes() function can becaused to dereference an invalid or NULL pointer when reading, resulting ina Denial of Service.The function PKCS7_digest_from_attributes() accesses the message digest attributevalue without validating its type. When the type is not V_ASN1_OCTET_STRING,this results in accessing invalid memory through the ASN1_TYPE union, causinga crash.Exploiting this vulnerability requires an attacker to provide a malformedsigned PKCS#7 to an application that verifies it. The impact of theexploit is just a Denial of Service, the PKCS7 API is legacy and applicationsshould be using the CMS API instead. For these reasons the issue wasassessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#7 parsing implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libopenssl1_0_0 < 1.0.2p-3.103.1 (version in image is 1.0.2p-3.98.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: fix potential kgd_mem UAFskgd_mem pointers returned by kfd_process_device_translate_handle areonly guaranteed to be valid while p->mutex is held. As soon as the mutexis unlocked, another thread can free the BO.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: fix stack overflow in line6_midi_transmitCorrectly calculate available space including the size of the chunkbuffer. This fixes a buffer overflow when multiple MIDI sysexmessages are sent to a PODxt device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid double brelse() in udf_rename()syzbot reported a warning like below [1]:VFS: brelse: Trying to free free bufferWARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0...Call Trace: invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ? generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ? __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0 __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe cause of the issue is that brelse() is called on both ofibh.sbhand ofibh.ebh by udf_find_entry() when it returns NULL. However,brelse() is called by udf_rename(), too. So, b_count on buffer_headbecomes unbalanced.This patch fixes the issue by not calling brelse() by udf_rename()when udf_find_entry() returns NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: smscufx: Fix several use-after-free bugsSeveral types of UAFs can occur when physically removing a USB device.Adds ufx_ops_destroy() function to .fb_destroy of fb_ops, andin this function, there is kref_put() that finally calls ufx_free().This fix prevents multiple UAFs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't trust firmware n_channelsIf the firmware sends us a corrupted MCC response withn_channels much larger than the command response can be,we might copy far too much (uninitialized) memory andeven crash if the n_channels is large enough to make itrun out of the one page allocated for the FW response.Fix that by checking the lengths. Doing a < comparisonwould be sufficient, but the firmware should be doingit correctly, so check more strictly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Fix crash due to uninitialized current_vmcsKVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running asa nested hypervisor on top of Hyper-V. When MSR bitmap is updated,evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to markthat the msr bitmap was changed.vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr-> vmx_msr_bitmap_l01_changed which in the end calls this function. Thefunction checks for current_vmcs if it is null but the check isinsufficient because current_vmcs is not initialized. Because of this, thecode might incorrectly write to the structure pointed by current_vmcs valueleft by another task. Preemption is not disabled, the current task can bepreempted and moved to another CPU while current_vmcs is accessed multipletimes from evmcs_touch_msr_bitmap() which leads to crash.The manipulation of MSR bitmaps by callers happens only for vmcs01 so thesolution is to use vmx->vmcs01.vmcs instead of current_vmcs. BUG: kernel NULL pointer dereference, address: 0000000000000338 PGD 4e1775067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI ... RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel] ... Call Trace: vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel] vmx_vcpu_create+0xe6/0x540 [kvm_intel] kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm] kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm] kvm_vm_ioctl+0x53f/0x790 [kvm] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- containerd < 1.7.29-16.105.1 (version in image is 1.7.27-16.100.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools > 0-0 (version in image is 2.48.2-12.46.1).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools > 0-0 (version in image is 2.48.2-12.46.1).
-
Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix a race condition between login_work and the login threadIn case a malicious initiator sends some random data immediately after alogin PDU; the iscsi_target_sk_data_ready() callback will schedule thelogin_work and, at the same time, the negotiation may end without clearingthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges arerequired to complete the login).The login has been completed but the login_work function will find theLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from reschedulingitself; at this point, if the initiator drops the connection, theiscsit_conn structure will be freed, login_work will dereference a releasedsocket structure and the kernel crashes.BUG: kernel NULL pointer dereference, address: 0000000000000230PF: supervisor write access in kernel modePF: error_code(0x0002) - not-present pageWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]RIP: 0010:_raw_read_lock_bh+0x15/0x30Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0Fix this bug by forcing login_work to stop after the login has beencompleted and the socket callbacks have been restored.Add a comment to clearify the return values of iscsi_target_do_login()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: call __btrfs_remove_free_space_cache_locked on cache load failureNow that lockdep is staying enabled through our entire CI runs I startedseeing the following stack in generic/475------------[ cut here ]------------WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014Workqueue: btrfs-cache btrfs_work_helperRIP: 0010:btrfs_discard_update_discardable+0x98/0xb0RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831eRBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock);We have a temporary free space ctl for loading the free space cache inorder to avoid having allocations happening while we're loading thecache. When we hit an error we free it all up, however this also callsbtrfs_discard_update_discardable, which requiresblock_group->free_space_ctl->tree_lock to be held. However this is ourtemporary ctl so this lock isn't held. Fix this by calling__btrfs_remove_free_space_cache_locked instead so that we only clean upthe entries and do not mess with the discardable stats.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:class: fix possible memory leak in __class_register()If class_add_groups() returns error, the 'cp->subsys' need beunregister, and the 'cp' need be freed.We can not call kset_unregister() here, because the 'cls' willbe freed in callback function class_release() and it's alsofreed in caller's error path, it will cause double free.So fix this by calling kobject_del() and kfree_const(name) tocleanup kobject. Besides, call kfree() to free the 'cp'.Fault injection test can trigger this:unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49aunreferenced object 0xffff888037274000 (size 1024): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probeof_phy_find_device() return device node with refcount incremented.Call put_device() to relese it when not needed anymore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb()It is possible that skb is freed in ath9k_htc_rx_msg(), thenusb_submit_urb() fails and we try to free skb again. It causesuse-after-free bug. Moreover, if alloc_skb() fails, urb->context becomesNULL but rx_buf is not freed and there can be a memory leak.The patch removes unnecessary nskb and makes skb processing more clear: itis supposed that ath9k_htc_rx_msg() either frees old skb or passes itsmanaging to another callback function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_noneAfter grabbing q->sysfs_lock, q->elevator may become NULL because ofelevator switch.Fix the NULL dereference on q->elevator by checking it with lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: call kmem_cache_destroy() in dm_integrity_init() error pathOtherwise the journal_io_cache will leak if dm_register_target() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: fix memory leak of remain_skbshif_dev->remain_skb is allocated and used exclusively inath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb isprocessed and subsequently freed (in error paths) only during the nextcall of ath9k_hif_usb_rx_stream().So, if the urbs are deallocated between those two calls due to the devicedeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()is not called next time and the allocated remain_skb is leaked. Our localSyzkaller instance was able to trigger that.remain_skb makes sense when receiving two consecutive urbs which arelogically linked together, i.e. a specific data field from the first skbindicates a cached skb to be allocated, memcpy'd with some data andsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbsdeallocation supposedly makes that link irrelevant so we need to free thecached skb in those cases.Fix the leak by introducing a function to explicitly free remain_skb (ifit is not NULL) when the rx urbs have been deallocated. remain_skb is NULLwhen it has not been allocated at all (hif_dev struct is kzalloced) orwhen it has been processed in next call to ath9k_hif_usb_rx_stream().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: rockchip: Fix refcount leak in rockchip_pinctrl_parse_groupsof_find_node_by_phandle() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix memleak for 'conf->bio_split'In the error path of raid10_run(), 'conf' need be freed, however,'conf->bio_split' is missed and memory will be leaked.Since there are 3 places to free 'conf', factor out a helper to fix theproblem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:autofs: fix memory leak of waitqueues in autofs_catatonic_modeSyzkaller reports a memory leak:BUG: memory leakunreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:870 [inline] [] __se_sys_ioctl fs/ioctl.c:856 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdautofs_wait_queue structs should be freed if their wait_ctr becomes zero.Otherwise they will be lost.In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a newwaitqueue struct is allocated in autofs_wait(), its initial wait_ctrequals 2. After that wait_event_killable() is interrupted (it returns-ERESTARTSYS), so that 'wq->name.name == NULL' condition may be notsatisfied. Actually, this condition can be satisfied whenautofs_wait_release() or autofs_catatonic_mode() is called and, what isalso important, wait_ctr is decremented in those places. Upon the exit ofautofs_wait(), wait_ctr is decremented to 1. Then the unmounting processbegins: kill_sb calls autofs_catatonic_mode(), which should have freed thewaitqueues, but it only decrements its usage counter to zero which is nota correct behaviour.edit:imkThis description is of course not correct. The umount performed as a resultof an expire is a umount of a mount that has been automounted, it's not theautofs mount itself. They happen independently, usually after everythingmounted within the autofs file system has been expired away. If everythinghasn't been expired away the automount daemon can still exit leaving mountsin place. But expires done in both cases will result in a notification thatcalls autofs_wait_release() with a result status. The problem case is thesummary execution of of the automount daemon. In this case any waitingprocesses won't be woken up until either they are terminated or the mountis umounted.end edit: imkSo in catatonic mode we should free waitqueues which counter becomes zero.edit: imkInitially I was concerned that the calling of autofs_wait_release() andautofs_catatonic_mode() was not mutually exclusive but that can't be thecase (obviously) because the queue entry (or entries) is removed from thelist when either of these two functions are called. Consequently the waitentry will be freed by only one of these functions or by the woken processin autofs_wait() depending on the order of the calls.end edit: imk
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix lockdep splat and potential deadlock after failure running delayed itemsWhen running delayed items we are holding a delayed node's mutex and thenwe will attempt to modify a subvolume btree to insert/update/delete thedelayed items. However if have an error during the insertions for example,btrfs_insert_delayed_items() may return with a path that has locked extentbuffers (a leaf at the very least), and then we attempt to release thedelayed node at __btrfs_run_delayed_items(), which requires taking thedelayed node's mutex, causing an ABBA type of deadlock. This was reportedby syzbot and the lockdep splat is the following: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted ------------------------------------------------------ syz-executor.2/13257 is trying to acquire lock: ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: __lock_release kernel/locking/lockdep.c:5475 [inline] lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline] btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239 search_leaf fs/btrfs/ctree.c:1986 [inline] btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline] btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline] __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flush_space+0x269/0xe70 fs/btrfs/space-info.c:723 btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races around sk->sk_shutdown.KCSAN found a data race around sk->sk_shutdown where unix_release_sock()and unix_shutdown() update it under unix_state_lock(), OTOH unix_poll()and unix_dgram_poll() read it locklessly.We need to annotate the writes and reads with WRITE_ONCE() and READ_ONCE().BUG: KCSAN: data-race in unix_poll / unix_release_sockwrite to 0xffff88800d0f8aec of 1 bytes by task 264 on cpu 0: unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631 unix_release+0x59/0x80 net/unix/af_unix.c:1042 __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1397 __fput+0x179/0x5e0 fs/file_table.c:321 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88800d0f8aec of 1 bytes by task 222 on cpu 1: unix_poll+0xa3/0x2a0 net/unix/af_unix.c:3170 sock_poll+0xcf/0x2b0 net/socket.c:1385 vfs_poll include/linux/poll.h:88 [inline] ep_item_poll.isra.0+0x78/0xc0 fs/eventpoll.c:855 ep_send_events fs/eventpoll.c:1694 [inline] ep_poll fs/eventpoll.c:1823 [inline] do_epoll_wait+0x6c4/0xea0 fs/eventpoll.c:2258 __do_sys_epoll_wait fs/eventpoll.c:2270 [inline] __se_sys_epoll_wait fs/eventpoll.c:2265 [inline] __x64_sys_epoll_wait+0xcc/0x190 fs/eventpoll.c:2265 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0x00 -> 0x03Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 222 Comm: dbus-broker Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amba: bus: fix refcount leakcommit 5de1540b7bc4 ("drivers/amba: create devices from device tree")increases the refcount of of_node, but not releases it inamba_device_release, so there is refcount leak. By using of_node_putto avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix lost destroy smbd connection when MR allocate failedIf the MR allocate failed, the smb direct connection info is NULL,then smbd_destroy() will directly return, then the connection infowill be leaked.Let's set the smb direct connection info to the server before callsmbd_destroy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()'read' is freed when it is known to be NULL, but not when a read erroroccurs.Revert the logic to avoid a small leak, should a m920x_read() call fail.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- 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.275.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- grub2 > 0-0 (version in image is 2.02-190.1).
-
Description: When setting up interrupt remapping for legacy PCI(-X) devices,including PCI(-X) bridges, a lookup of the upstream bridge is required.This lookup, itself involving acquiring of a lock, is done in a contextwhere acquiring that lock is unsafe. This can lead to a deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- xen-libs > 0-0 (version in image is 4.12.4_62-3.130.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.16.0-rc3-build2+ #1301 Tainted: G S W------------------------------------------------------cifsd/6055 is trying to acquire lock:ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30other info that might help us debug this:Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK ***3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structureIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, theresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() mayoccur before sli4_hba.hdwqs are allocated. This may result in a nullpointer dereference when attempting to take the abts_io_buf_list_lock forthe first hardware queue. Fix by adding a null ptr check onphba->sli4_hba.hdwq and early return because this situation means theremust have been an error during port initialization.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Check encryption key size on incoming connectionThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bitThis tests the security key with size from 1 to 15 bytes while theSecurity Mode 4 Level 4 requests 16 bytes key size.Currently PTS fails with the following logs:- expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt),but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information availableAnd HCI logs:< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)> HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7> ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64< ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix using smp_processor_id() in preemptible code warningsSyzbot reported the following warning:BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFor historical and portability reasons, the netif_rx() is usuallyrun in the softirq or interrupt context, this commit therefore addlocal_bh_disable/enable() protection in the usbnet_resume_rx().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process.A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libsystemd0 > 0-0 (version in image is 228-157.72.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Fix synchronous external abort on unbindA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind isexecuted after the configuration sequence described above:modprobe usb_f_ecmmodprobe libcompositemodprobe configfscd /sys/kernel/config/usb_gadgetmkdir -p g1cd g1echo "0x1d6b" > idVendorecho "0x0104" > idProductmkdir -p strings/0x409echo "0123456789" > strings/0x409/serialnumberecho "Renesas." > strings/0x409/manufacturerecho "Ethernet Gadget" > strings/0x409/productmkdir -p functions/ecm.usb0mkdir -p configs/c.1mkdir -p configs/c.1/strings/0x409echo "ECM" > configs/c.1/strings/0x409/configurationif [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1fiecho 11e20000.usb > UDCecho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbindThe displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1The issue occurs because usbhs_sys_function_pullup(), which accesses the IPregisters, is executed after the USBHS clocks have been disabled. Theproblem is reproducible on the Renesas RZ/G3S SoC starting with theaddition of module stop in the clock enable/disable APIs. With module stopfunctionality enabled, a bus error is expected if a master accesses amodule whose clock has been stopped and module stop activated.Disable the IP clocks at the end of remove.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_createWhen sync() and link() are called concurrently, both threads mayenter hfs_bnode_find() without finding the node in the hash tableand proceed to create it.Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it.Thread B also tries to create the same bnode, notices it has alreadybeen inserted, drops its own instance, and uses the hashed one withoutgetting the node.``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; }```However, hfs_bnode_find() requires each call to take a reference.Here both threads end up setting refcnt=1. When they later put the node,this triggers:BUG_ON(!atomic_read(&node->refcnt))In this scenario, Thread B in fact finds the node in the hash tablerather than creating a new one, and thus must take a reference.Fix this by calling hfs_bnode_get() when reusing a bnode newly created byanother thread to ensure the refcount is updated correctly.A similar bug was fixed in HFS long ago in commita9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")but the same issue remained in HFS+ until now.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: fix memory leak on usb_submit_urb() failureIn async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak. The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked. Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libssh-config > 0-0 (version in image is 0.9.8-3.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix slab-out-of-bounds in ses_enclosure_data_process()A fix for:BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses]Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, weexpect the size to be sanitized before first access to addl_desc_ptr[1].Make sure we don't walk beyond end of page.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- containerd > 0-0 (version in image is 1.7.27-16.100.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-mem2mem: add lock to protect parameter num_rdyGetting below error when using KCSAN to check the driver. Adding lock toprotect parameter num_rdy when getting the value with function:v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queuekworker/u16:3: [name:report&]kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A flaw was found in github.com/go-viper/mapstructure/v2, in the field processing component using mapstructure.WeakDecode. This vulnerability allows information disclosure through detailed error messages that may leak sensitive input values via malformed user-supplied data processed in security-critical contexts.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- docker > 0-0 (version in image is 28.4.0_ce-98.143.1).
-
Description: A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A heap-based buffer over-read issue was discovered in the function sec_merge_hash_lookup in merge.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31, because _bfd_add_merge_section mishandles section merges when size is not a multiple of entsize. A specially crafted ELF allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspaceCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes/dev/kvm to userspace and thus allows userspace to create VMs (and callother ioctls). E.g. KVM will encounter a NULL pointer when attempting toadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able tocreate a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: lvds: fix PM usage counter unbalance in poweronpm_runtime_get_sync will increment pm usage counter even it failed.Forgetting to putting operation will result in reference leak here.We fix it by replacing it with the newest pm_runtime_resume_and_getto keep usage counter balanced.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash when I/O abort times outWhile performing CPU hotplug, a crash with the following stack was seen:Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0On abort timeout, completion was called without checking if the I/O wasalready completed.Verify that I/O and abort request are indeed outstanding before attemptingcompletion.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()As comment of pci_get_class() says, it returns a pci_device with itsrefcount increased and decreased the refcount for the input parameter@from if it is not NULL.If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, weneed to call pci_dev_put() to decrease the refcount. Add the missingpci_dev_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/xen: Fix memory leak in xen_init_lock_cpu()In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(),if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may leadto a memory leak issue, fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix memory leak in ocfs2_mount_volume()There is a memory leak reported by kmemleak: unreferenced object 0xffff88810cc65e60 (size 32): comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s) hex dump (first 32 bytes): 10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................ 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................ backtrace: [] __kmalloc+0x4d/0x150 [] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2] [] ocfs2_check_volume+0x485/0x900 [ocfs2] [] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2] [] ocfs2_fill_super+0xe0b/0x1740 [ocfs2] [] mount_bdev+0x312/0x400 [] legacy_get_tree+0xed/0x1d0 [] vfs_get_tree+0x7d/0x230 [] path_mount+0xd62/0x1760 [] do_mount+0xca/0xe0 [] __x64_sys_mount+0x12c/0x1a0 [] do_syscall_64+0x35/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0This call stack is related to two problems. Firstly, the ocfs2 super uses"replay_map" to trace online/offline slots, in order to recover offlineslots during recovery and mount. But when ocfs2_truncate_log_init()returns an error in ocfs2_mount_volume(), the memory of "replay_map" willnot be freed in error handling path. Secondly, the memory of "replay_map"will not be freed if d_make_root() returns an error in ocfs2_fill_super().But the memory of "replay_map" will be freed normally when completingrecovery and mount in ocfs2_complete_mount_recovery().Fix the first problem by adding error handling path to free "replay_map"when ocfs2_truncate_log_init() fails. And fix the second problem bycalling ocfs2_free_replay_slots(osb) in the error handling path"out_dismount". In addition, since ocfs2_free_replay_slots() is static,it is necessary to remove its static attribute and declare it in headerfile.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()When insert and remove the orangefs module, then debug_help_string willbe leaked: unreferenced object 0xffff8881652ba000 (size 4096): comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s) hex dump (first 32 bytes): 43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79 Client Debug Key 77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77 words are unknow backtrace: [<0000000004e6f8e3>] kmalloc_trace+0x27/0xa0 [<0000000006f75d85>] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs] [<0000000091270a2a>] _sub_I_65535_1+0x57/0xf70 [crc_itu_t] [<000000004b1ee1a3>] do_one_initcall+0x87/0x2a0 [<000000001d0614ae>] do_init_module+0xdf/0x320 [<00000000efef068c>] load_module+0x2f98/0x3330 [<000000006533b44d>] __do_sys_finit_module+0x113/0x1b0 [<00000000a0da6f99>] do_syscall_64+0x35/0x80 [<000000007790b19b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0When remove the module, should always free debug_help_string. Shouldalways free the allocated buffer when change the free_debug_help_string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ensure sane device mtu in tunnelsAnother syzbot report [1] with no reproducer hintsat a bug in ip6_gre tunnel (dev:ip6gretap0)Since ipv6 mcast code makes sure to read dev->mtu onceand applies a sanity check on it (see commit b9b312a7a451"ipv6: mcast: better catch silly mtu values"), a remainingpossibility is that a layer is able to set dev->mtu toan underflowed value (high order bit set).This could happen indeed in ip6gre_tnl_link_config_route(),ip6_tnl_link_config() and ipip6_tunnel_bind_dev()Make sure to sanitize mtu value in a local variable beforeit is written once on dev->mtu, as lockless readers couldcatch wrong temporary value.[1]skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0------------[ cut here ]------------kernel BUG at net/core/skbuff.c:120Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022Workqueue: mld mld_ifc_workpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116sp : ffff800020dd3b60x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089Call trace:skb_panic+0x4c/0x50 net/core/skbuff.c:116skb_over_panic net/core/skbuff.c:125 [inline]skb_put+0xd4/0xdc net/core/skbuff.c:2049ip6_mc_hdr net/ipv6/mcast.c:1714 [inline]mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765add_grhead net/ipv6/mcast.c:1851 [inline]add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653process_one_work+0x2d8/0x504 kernel/workqueue.c:2289worker_thread+0x340/0x610 kernel/workqueue.c:2436kthread+0x12c/0x158 kernel/kthread.c:376ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leakIn check_acpi_tpm2(), we get the TPM2 table just to makesure the table is there, not used after the init, so theacpi_put_table() should be added to release the ACPI memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: amd - Fix PCI device refcount 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() for the normal and error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix deadloop issue on reading trace_pipeSoft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Through the vmcore, I found it's because in tracing_read_pipe(),ring_buffer_empty_cpu() found some buffer is not empty but then itcannot read anything due to "rb_num_of_entries() == 0" always true,Then it infinitely loop the procedure due to user buffer not beenfilled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }By some analyzing, I found that when resetting ringbuffer, the 'entries'of its pages are not all cleared (see rb_reset_cpu()). Then when reducingthe ringbuffer, and if some reduced pages exist dirty 'entries' data, theywill be added into 'cpu_buffer->overrun' (see rb_remove_pages()), whichcause wrong 'overrun' count and eventually cause the deadloop issue.To fix it, we need to clear every pages in rb_reset_cpu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: Fix __bch_btree_node_alloc to make the failure behavior consistentIn some specific situations, the return value of __bch_btree_node_allocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.Fix it by initializing the return value in __bch_btree_node_alloc.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix one memleak in __inet_del_ifa()I got the below warning when do fuzzing test:unregister_netdevice: waiting for bond0 to become free. Usage count = 2It can be repoduced via:ip link add bond0 type bondsysctl -w net.ipv4.conf.bond0.promote_secondaries=1ip addr add 4.117.174.103/0 scope 0x40 dev bond0ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0ip addr del 4.117.174.103/0 scope 0x40 dev bond0ip link delete bond0 type bondIn this reproduction test case, an incorrect 'last_prim' is found in__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)is lost. The memory of the secondary address is leaked and the reference ofin_device and net_device is leaked.Fix this problem:Look for 'last_prim' starting at location of the deleted IP and insertingthe promoted IP into the location of 'last_prim'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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:
- 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.275.1).
-
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- containerd > 0-0 (version in image is 1.7.27-16.100.1).
-
Description: A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libgnutls30 > 0-0 (version in image is 3.4.17-8.20.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================Even though fbcon_init() checks beforehand if fb_match_mode() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not allow relocation of partially dropped subvolumes[BUG]There is an internal report that balance triggered transaction abort,with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]And btrfs check doesn't report anything wrong related to the extenttree.[CAUSE]The cause is a little complex, firstly the extent tree indeed doesn'thave the backref for 594526208.The extent tree only have the following two backrefs around that bytenron-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREEBut the such missing backref item is not an corruption on disk, as theoffending delayed ref belongs to subvolume 934, and that subvolume isbeing dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229And that offending tree block 594526208 is inside the dropped range ofthat subvolume. That explains why there is no backref item for thatbytenr and why btrfs check is not reporting anything wrong.But this also shows another problem, as btrfs will do all the orphansubvolume cleanup at a read-write mount.So half-dropped subvolume should not exist after an RW mount, andbalance itself is also exclusive to subvolume cleanup, meaning weshouldn't hit a subvolume half-dropped during relocation.The root cause is, there is no orphan item for this subvolume.In fact there are 5 subvolumes from around 2021 that have the sameproblem.It looks like the original report has some older kernels running, andcaused those zombie subvolumes.Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshotdeletion not triggered on mount") has long fixed the bug.[ENHANCEMENT]For repairing such old fs, btrfs-progs will be enhanced.Considering how delayed the problem will show up (at run delayed reftime) and at that time we have to abort transaction already, it is toolate.Instead here we reject any half-dropped subvolume for reloc tree at theearliest time, preventing confusion and extra time wasted on debuggingsimilar bugs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check NULL before accessing[WHAT]IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomicfails with NULL pointer dereference. This can be reproduced withboth an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ...(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: libsodium before ad3004e, in atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- libsodium23 > 0-0 (version in image is 1.0.16-1.9.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leakIn gs_can_open(), the URBs for USB-in transfers are allocated, added to theparent->rx_submitted anchor and submitted. In the complete callbackgs_usb_receive_bulk_callback(), the URB is processed and resubmitted. Ings_can_close() the URBs are freed by callingusb_kill_anchored_urbs(parent->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in gs_can_close().Fix the memory leak by anchoring the URB in thegs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: An issue was discovered in cp-demangle.c in GNU libiberty, as distributed in GNU Binutils 2.31. There is a stack consumption problem caused by the cplus_demangle_type function making recursive calls to itself in certain scenarios involving many 'P' characters.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The get_count function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31, allows remote attackers to cause a denial of service (malloc called with the result of an integer-overflowing calculation) or possibly have unspecified other impact via a crafted string, as demonstrated by c++filt.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in cp-demangle.c in GNU libiberty, as distributed in GNU Binutils 2.31. Stack Exhaustion occurs in the C++ demangling functions provided by libiberty, and there is a stack consumption problem caused by recursive stack frames: cplus_demangle_type, d_bare_function_type, d_function_type.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- libruby2_1-2_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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- rsync > 0-0 (version in image is 3.1.3-3.31.1).
-
Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.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: 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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Reinit port->pm on port specific driver unbindWhen we unbind a serial port hardware specific 8250 driver, the genericserial8250 driver takes over the port. After that we see an oops about 10seconds later. This can produce the following at least on some TI SoCs:Unhandled fault: imprecise external abort (0x1406)Internal error: : 1406 [#1] SMP ARMTurns out that we may still have the serial port hardware specific driverport->pm in use, and serial8250_pm() tries to call it after the portspecific driver is gone:serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c__tty_hangup.part.0 from disassociate_ctty+0x154/0x20cdisassociate_ctty from do_exit+0x744/0xaacdo_exit from do_group_exit+0x40/0x8cdo_group_exit from __wake_up_parent+0x0/0x1cLet's fix the issue by calling serial8250_set_defaults() inserial8250_unregister_port(). This will set the port back to usingthe serial8250 default functions, and sets the port->pm to point toserial8250_pm.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAFAfter a call to console_unlock() in vcs_write() the vc_data struct can befreed by vc_port_destruct(). Because of that, the struct vc_data pointermust be reloaded in the while loop in vcs_write() after console_lock() toavoid a UAF when vcs_size() is called.Syzkaller reported a UAF in vcs_size().BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119Call Trace: __asan_report_load4_noabort (mm/kasan/report_generic.c:380)vcs_size (drivers/tty/vt/vc_screen.c:215)vcs_write (drivers/tty/vt/vc_screen.c:664)vfs_write (fs/read_write.c:582 fs/read_write.c:564)... Allocated by task 1213:kmalloc_trace (mm/slab_common.c:1064)vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680 drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058)con_install (drivers/tty/vt/vt.c:3334)tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415 drivers/tty/tty_io.c:1392)tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128)chrdev_open (fs/char_dev.c:415)do_dentry_open (fs/open.c:921)vfs_open (fs/open.c:1052)...Freed by task 4116:kfree (mm/slab_common.c:1016)vc_port_destruct (drivers/tty/vt/vt.c:1044)tty_port_destructor (drivers/tty/tty_port.c:296)tty_port_put (drivers/tty/tty_port.c:312)vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)tty_ioctl (drivers/tty/tty_io.c:2778)...The buggy address belongs to the object at ffff8880beab8800 which belongs to the cache kmalloc-1k of size 1024The buggy address is located 424 bytes inside of freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)The buggy address belongs to the physical page:page:00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbeab8head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)page_type: 0xffffffff()raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb>ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================Disabling lock debugging due to kernel taint
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before initblk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0This happens because iocg->ioc is NULL. The field is initialized byioc_pd_init() and never cleared. The NULL deref is caused byblkcg_activate_policy() installing blkg_policy_data before initializing it.blkcg_activate_policy() was doing the following:1. Allocate pd's for all existing blkg's and install them in blkg->pd[].2. Initialize all pd's.3. Online all pd's.blkcg_activate_policy() only grabs the queue_lock and may release andre-acquire the lock as allocation may need to sleep. ioc_weight_write()grabs blkcg->lock and iterates all its blkg's. The two can race and ifioc_weight_write() runs during #1 or between #1 and #2, it can encounter apd which is not initialized yet, leading to crash.The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c "echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weightwith the following patch applied:> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c> index fc49be622e05..38d671d5e10c 100644> --- a/block/blk-cgroup.c> +++ b/block/blk-cgroup.c> @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)> pd->online = false;> }>> + if (system_state == SYSTEM_RUNNING) {> + spin_unlock_irq(&q->queue_lock);> + ssleep(1);> + spin_lock_irq(&q->queue_lock);> + }> +> /* all allocated, init in the same order */> if (pol->pd_init_fn)> list_for_each_entry_reverse(blkg, &q->blkg_list, q_node)I don't see a reason why all pd's should be allocated, initialized andonlined together. The only ordering requirement is that parent blkgs to beinitialized and onlined before children, which is guaranteed from thewalking order. Let's fix the bug by allocating, initializing and onlining pdfor each blkg and holding blkcg->lock over initialization and onlining. Thisensures that an installed blkg is always fully initialized and onlinedremoving the the race window.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Add a check for valid 'mad_agent' pointerWhen unregistering MAD agent, srpt module has a non-null checkfor 'mad_agent' pointer before invoking ib_unregister_mad_agent().This check can pass if 'mad_agent' variable holds an error value.The 'mad_agent' can have an error value for a short window whensrpt_add_one() and srpt_remove_one() is executed simultaneously.In srpt module, added a valid pointer check for 'sport->mad_agent'before unregistering MAD agent.This issue can hit when RoCE driver unregisters ib_deviceStack Trace:------------BUG: kernel NULL pointer dereference, address: 000000000000004dPGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0Oops: 0002 [#1] PREEMPT SMP NOPTICPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: PHardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020Workqueue: bnxt_re bnxt_re_task [bnxt_re]RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40Call Trace: ib_unregister_mad_agent+0x46/0x2f0 [ib_core] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready ? __schedule+0x20b/0x560 srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt] srpt_remove_one+0x20/0x150 [ib_srpt] remove_client_context+0x88/0xd0 [ib_core] bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex disable_device+0x8a/0x160 [ib_core] bond0: active interface up! ? kernfs_name_hash+0x12/0x80 (NULL device *): Bonding Info Received: rdev: 000000006c0b8247 __ib_unregister_device+0x42/0xb0 [ib_core] (NULL device *): Master: mode: 4 num_slaves:2 ib_unregister_device+0x22/0x30 [ib_core] (NULL device *): Slave: id: 105069936 name:p2p1 link:0 state:0 bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re] bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,running at UDMA/33.The issue can be reproduced by running the same command with a cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- expat > 0-0 (version in image is 2.7.1-21.46.1).
-
Description: A flaw was found in the GnuTLS library, specifically in the gnutls_pkcs11_token_init() function that handles PKCS#11 token initialization. When a token label longer than expected is processed, the function writes past the end of a fixed-size stack buffer. This programming error can cause the application using GnuTLS to crash or, in certain conditions, be exploited for code execution. As a result, systems or applications relying on GnuTLS may be vulnerable to a denial of service or local privilege escalation attacks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libgnutls30 > 0-0 (version in image is 3.4.17-8.20.1).
-
Description: The pe_bfd_read_buildid function in peicode.h in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, does not validate size and offset values in the data dictionary, which allows remote attackers to cause a denial of service (segmentation violation and application crash) or possibly have unspecified other impact via a crafted PE file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory access exists in bfd_zalloc in opncls.c. Attackers could leverage this vulnerability to cause a denial of service (application crash) via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: A NULL pointer dereference was discovered in elf_link_add_object_symbols in elflink.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31.1. This occurs for a crafted ET_DYN with no program headers. A specially crafted ELF file allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: In SQLite through 3.22.0, databases whose schema is corrupted using a CREATE TABLE AS statement could cause a NULL pointer dereference, related to build.c and prepare.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- sqlite3-tcl > 0-0 (version in image is 3.50.2-9.41.1).
-
Description: The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to use of the ssl_context, ca_certs, or ca_certs_dir argument.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: The coff_slurp_line_table function in coffcode.h in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, allows remote attackers to cause a denial of service (invalid memory access and application crash) or possibly have unspecified other impact via a crafted PE file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools > 0-0 (version in image is 2.48.2-12.46.1).
-
Description: The getNodeSize function in ext/rtree/rtree.c in SQLite through 3.19.3, as used in GDAL and other products, mishandles undersized RTree blobs in a crafted database, leading to a heap-based buffer over-read or possibly unspecified other impact.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- sqlite3-tcl > 0-0 (version in image is 3.50.2-9.41.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs().KCSAN found a data race in sock_recv_cmsgs() where the read accessto sk->sk_stamp needs READ_ONCE().BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsgwrite (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0: sock_write_timestamp include/net/sock.h:2670 [inline] sock_recv_cmsgs include/net/sock.h:2722 [inline] packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1: sock_recv_cmsgs include/net/sock.h:2721 [inline] packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0xffffffffc4653600 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: The display_debug_ranges function in dwarf.c in GNU Binutils 2.30 allows remote attackers to cause a denial of service (integer overflow and application crash) or possibly have unspecified other impact via a crafted ELF file, as demonstrated by objdump.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libfl2 > 0-0 (version in image is 2.6.4-9.7.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:capabilities: fix undefined behavior in bit shift for CAP_TO_MASKShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0 __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()Syzkaller reports a long-known leak of urbs inath9k_hif_usb_dealloc_tx_urbs().The cause of the leak is that usb_get_urb() is called but usb_free_urb()(or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev orurb->ep fields have not been initialized and usb_kill_urb() returnsimmediately.The patch removes trying to kill urbs located in hif_dev->tx.tx_bufbecause hif_dev->tx.tx_buf is not supposed to contain urbs which are inpending state (the pending urbs are stored in hif_dev->tx.tx_pending).The tx.tx_lock is acquired so there should not be any changes in the list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), forcrafted filesystem image can contain bogus length. There conditions arenot kernel bugs that can justify kernel to panic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix GID entry ref leak when create_ah failsIf AH create request fails, release sgid_attr to avoid GID entryreferrence leak reported while releasing GID table
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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:
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: remove wrong sb->s_sequence checkJournal emptiness is not determined by sb->s_sequence == 0 but rather bysb->s_start == 0 (which is set a few lines above). Furthermore 0 is avalid transaction ID so the check can spuriously trigger. Remove theinvalid WARN_ON.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kexec: Enable SMT before waking offline CPUsIf SMT is disabled or a partial SMT state is enabled, when a new kernelimage is loaded for kexec, on reboot the following warning is observed:kexec: Waking offline cpu 228.WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc[snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ecThis occurs as add_cpu() fails due to cpu_bootable() returning false forCPUs that fail the cpu_smt_thread_allowed() check or non primarythreads if SMT is disabled.Fix the issue by enabling SMT and resetting the number of SMT threads tothe number of threads per core, before attempting to wake up all presentCPUs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.90.1).
-
Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.90.1).
-
Description: OpenLDAP Lightning Memory-Mapped Database (LMDB) versions up to and including 0.9.14, prior to commit 8e1fda8, contain a heap buffer underflow in the readline() function of mdb_load. When processing malformed input containing an embedded NUL byte, an unsigned offset calculation can underflow and cause an out-of-bounds read of one byte before the allocated heap buffer. This can cause mdb_load to crash, leading to a limited denial-of-service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libldap-2_4-2 > 0-0 (version in image is 2.4.41-22.24.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: fix memory leak in update_eth_regs_async()When asynchronously writing to the device registers and if usb_submit_urb()fail, the code fail to release allocated to this point resources.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: The demangler in GNU Libiberty allows remote attackers to cause a denial of service (infinite loop, stack overflow, and crash) via a cycle in the references of remembered mangled types.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- crash > 0-0 (version in image is 7.2.1-8.19.2).
-
Description: elfcomm.c in readelf in GNU Binutils 2.29 allows remote attackers to cause a denial of service (excessive memory allocation) or possibly have unspecified other impact via a crafted ELF file that triggers a "buffer overflow on fuzzed archive header," related to an uninitialized variable, an improper conditional jump, and the get_archive_member_name, process_archive_index_and_symbols, and setup_archive functions.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The _bfd_elf_parse_gnu_properties function in elf-properties.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, does not prevent negative pointers, which allows remote attackers to cause a denial of service (out-of-bounds read and application crash) or possibly have unspecified other impact via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: coffgen.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, does not validate the symbol count, which allows remote attackers to cause a denial of service (integer overflow and application crash, or excessive memory allocation) or possibly have unspecified other impact via a crafted PE file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: process_cu_tu_index in dwarf.c in GNU Binutils 2.30 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted binary file, as demonstrated by readelf.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: concat_filename in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted binary file, as demonstrated by nm-new.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The ignore_section_sym function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, does not validate the output_section pointer in the case of a symtab entry with a "SECTION" type that has a "0" value, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted file, as demonstrated by objcopy.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory access exists in _bfd_stab_section_find_nearest_line in syms.c. Attackers could leverage this vulnerability to cause a denial of service (application crash) via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory address dereference was discovered in read_reloc in reloc.c. The vulnerability causes a segmentation fault and application crash, which leads to denial of service, as demonstrated by objdump, because of missing _bfd_clear_contents bounds checking.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in the merge_strings function in merge.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. There is a NULL pointer dereference in _bfd_add_merge_section when attempting to merge sections with large alignments. A specially crafted ELF allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: An issue was discovered in elf_link_input_bfd in elflink.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. There is a NULL pointer dereference in elf_link_input_bfd when used for finding STT_TLS symbols without any TLS section. A specially crafted ELF allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: load_specific_debug_section in objdump.c in GNU Binutils through 2.31.1 contains an integer overflow vulnerability that can trigger a heap-based buffer overflow via a crafted section size.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The parse_die function in dwarf1.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (integer overflow and application crash) via an ELF file with corrupt dwarf1 debug information, as demonstrated by nm.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The swap_std_reloc_in function in aoutx.h in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (aout_32_swap_std_reloc_out NULL pointer dereference and application crash) via a crafted ELF file, as demonstrated by objcopy.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The bfd_section_from_shdr function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (segmentation fault) via a large attribute section.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix refcount bug in sk_psock_get (2)Syzkaller reports refcount bug as follows:------------[ cut here ]------------refcount_t: saturated; leaking memory.WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19Modules linked in:CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel willreplaces TCP with SMC. In order to forward wakeupsmc socket waitqueue after fallback, kernel will setsclcsk->sk_user_data to origin smc socket insmc_fback_replace_callbacks().Later, in shutdown syscall, kernel will callssk_psock_get(), which treats the clcsk->sk_user_dataas psock type, triggering the refcnt warning.So, the root cause is that smc and psock, both will usesk_user_data field. So they will mismatch this fieldeasily.This patch solves it by using another bit(defined asSK_USER_DATA_PSOCK) in PTRMASK, to mark whethersk_user_data points to a psock object or not.This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e("net, sk_msg: Clear sk_user_data pointer on clone if tagged").For there will possibly be more flags in the sk_user_data field,this patch also refactor sk_user_data flags code to be more genericto improve its maintainability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: fix possible memory leak in snd_ac97_dev_register()If device_register() fails in snd_ac97_dev_register(), it shouldcall put_device() to give up reference, or the name allocated indev_set_name() is leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix xid leak in cifs_copy_file_range()If the file is used by swap, before return -EOPNOTSUPP, shouldfree the xid, otherwise, the xid will be leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()As the comment of pci_get_domain_bus_and_slot() says, it returnsa PCI device with refcount incremented, so it doesn't need tocall an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCIdevice needs to be put in the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hpsa: Fix possible memory leak in hpsa_init_one()The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, inhpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps toclean1 directly, which frees h and leaks the h->reply_map.Fix by calling hpda_free_ctlr_info() to release h->replay_map and h insteadfree h directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acct: fix potential integer overflow in encode_comp_t()The integer overflow is descripted with following codes: > 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 }Currently comp_t is defined as type of '__u16', but the variable 'exp' istype of 'int', so overflow would happen when variable 'exp' in line 343 isgreater than 65535.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:configfs: fix possible memory leak in configfs_create_dir()kmemleak reported memory leaks in configfs_create_dir():unreferenced object 0xffff888009f6af00 (size 192): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ...unreferenced object 0xffff888003ba7180 (size 96): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ...This is because the refcount is not correct in configfs_make_dirent().For normal stage, the refcount is changing as:configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2...configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ... *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, releaseHowever, if we failed in configfs_create():configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode);There is no inode in the error path, so the configfs_d_iput() is lostand makes sd and fragment memory leaked.To fix this, when we failed in configfs_create(), manually callconfigfs_put(sd) to keep the refcount correct.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()There is a memory leaks problem reported by kmemleak:unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes):ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace:[] __kmalloc+0x4d/0x150[] ubi_eba_create_table+0x76/0x170 [ubi][] ubi_resize_volume+0x1be/0xbc0 [ubi][] ubi_cdev_ioctl+0x701/0x1850 [ubi][] __x64_sys_ioctl+0x11d/0x170[] do_syscall_64+0x35/0x80[] entry_SYSCALL_64_after_hwframe+0x46/0xb0This is due to a mismatch between create and destroy interfaces, andin detail that "new_eba_tbl" created by ubi_eba_create_table() butdestroyed by kfree(), while will causing "new_eba_tbl->entries" notfreed.Fix it by replacing kfree(new_eba_tbl) withubi_eba_destroy_table(new_eba_tbl)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Don't leak some plane stateApparently no one noticed that mdp5 plane states leak like a sieveever since we introduced plane_state->commit refcount a few years agoin 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state tooearly by tracking commits, v3.")Fix it by using the right helpers.Patchwork: https://patchwork.freedesktop.org/patch/551236/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix leak in devfreq_dev_release()srcu_init_notifier_head() allocates resources that need to be releasedwith a srcu_cleanup_notifier_head() call.Reported by kmemleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: amd: display: Fix memory leakageThis commit fixes memory leakage in dc_construct_ctx() function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: Fix memory leak for detached NAPI queue.syzkaller reported [0] memory leaks of sk and skb related to the TUNdevice with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun);If we enable NAPI and multi-queue on a TUN device, we can put skb intotfile->sk.sk_write_queue after the queue is detached. We should preventit by checking tfile->detached before queuing skb.Note this must be done under tfile->sk.sk_write_queue.lock because write()and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there wouldbe a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb)Another solution is to call tun_queue_purge() when closing andreattaching the detached queue, but it could paper over anotherproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.[0]:unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdcunreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [<---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clkWhen the best clk is searched, we iterate over all possible clk.If we find a better match, the previous one, if any, needs to be freed.If a better match has already been found, we still need to free the newone, otherwise it leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probeSmatch reports:drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.timer_baseaddr may have the problem of not being released after use,I replaced it with the devm_of_iomap() function and added the clk_put()function to cleanup the "clk_ce" and "clk_cs".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knodeWhen u32_replace_hw_knode fails, we need to undo the tcf_bind_filteroperation done at u32_set_parms.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: fix possible memory leak in ibmebus_bus_init()If device_register() returns error in ibmebus_bus_init(), name of kobjectwhich is allocated in dev_set_name() called in device_add() is leaked.As comment of device_add() says, it should call put_device() to dropthe reference count that was set in device_initialize() when it fails,so the name can be freed in kobject_cleanup().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/client: Fix memory leak in drm_client_target_cloneddmt_mode is allocated and never freed in this function.It was found with the ast driver, but most drivers using generic fbdevsetup are probably affected.This fixes the following kmemleak report: backtrace: [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm] [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm] [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm] [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm] [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast] [<00000000987f19bb>] local_pci_probe+0xdc/0x180 [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0 [<0000000000b85301>] process_one_work+0x8b7/0x1540 [<000000003375b17c>] worker_thread+0x70a/0xed0 [<00000000b0d43cd9>] kthread+0x29f/0x340 [<000000008d770833>] ret_from_fork+0x1f/0x30unreferenced object 0xff11000333089a00 (size 128):
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: safexcel - Cleanup ring IRQ workqueues on load failureA failure loading the safexcel driver results in the following warningon boot, because the IRQ affinity has not been correctly cleaned up.Ensure we clean up the affinity and workqueues on a failure to load thedriver.crypto-safexcel: probe of f2800000.crypto failed with error -2------------[ cut here ]------------WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3Hardware name: MikroTik RB5009 (DT)pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : free_irq+0x300/0x340lr : free_irq+0x2e0/0x340sp : ffff800008fa3890x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5ex14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0Call trace: free_irq+0x300/0x340 devm_irq_release+0x14/0x20 devres_release_all+0xa0/0x100 device_unbind_cleanup+0x14/0x60 really_probe+0x198/0x2d4 __driver_probe_device+0x74/0xdc driver_probe_device+0x3c/0x110 __driver_attach+0x8c/0x190 bus_for_each_dev+0x6c/0xc0 driver_attach+0x20/0x30 bus_add_driver+0x148/0x1fc driver_register+0x74/0x120 __platform_driver_register+0x24/0x30 safexcel_init+0x48/0x1000 [crypto_safexcel] do_one_initcall+0x4c/0x1b0 do_init_module+0x44/0x1cc load_module+0x1724/0x1be4 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x1c/0x24 invoke_syscall+0x44/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x20/0x80 el0_svc+0x14/0x4c el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x148/0x14c---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:quota: fix warning in dqgrab()There's issue as follows when do fault injection:WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0Modules linked in:CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541RIP: 0010:dquot_disable+0x13b7/0x18c0RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118FS: 00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: dquot_load_quota_sb+0xd53/0x1060 dquot_resume+0x172/0x230 ext4_reconfigure+0x1dc6/0x27b0 reconfigure_super+0x515/0xa90 __x64_sys_fsconfig+0xb19/0xd20 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdAbove issue may happens as follows:ProcessA ProcessB ProcessCsys_fsconfig vfs_fsconfig_locked reconfigure_super ext4_remount dquot_suspend -> suspend all type quota sys_fsconfig vfs_fsconfig_locked reconfigure_super ext4_remount dquot_resume ret = dquot_load_quota_sb add_dquot_ref do_open -> open file O_RDWR vfs_open do_dentry_open get_write_access atomic_inc_unless_negative(&inode->i_writecount) ext4_file_open dquot_file_open dquot_initialize __dquot_initialize dqget atomic_inc(&dquot->dq_count); __dquot_initialize __dquot_initialize dqget if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) ext4_acquire_dquot -> Return error DQ_ACTIVE_B flag isn't set dquot_disable invalidate_dquots if (atomic_read(&dquot->dq_count)) dqgrab WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) -> Trigger warningIn the above scenario, 'dquot->dq_flags' has no DQ_ACTIVE_B is normal whendqgrab().To solve above issue just replace the dqgrab() use in invalidate_dquots() withatomic_inc(&dquot->dq_count).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle case when repair happens with dev-replace[BUG]There is a bug report that a BUG_ON() in btrfs_repair_io_failure()(originally repair_io_failure() in v6.0 kernel) got triggered whenreplacing a unreliable disk: BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3 kernel BUG at fs/btrfs/extent_io.c:2380! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2 Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs] Call Trace: clean_io_failure+0x14d/0x180 [btrfs] end_bio_extent_readpage+0x412/0x6e0 [btrfs] ? __switch_to+0x106/0x420 process_one_work+0x1c7/0x380 worker_thread+0x4d/0x380 ? rescuer_thread+0x3a0/0x3a0 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30[CAUSE]Before the BUG_ON(), we got some read errors from the replace targetfirst, note the mirror number (3, which is beyond RAID1 duplication,thus it's read from the replace target device).Then at the BUG_ON() location, we are trying to writeback the repairedsectors back the failed device.The check looks like this: ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical, &map_length, &bioc, mirror_num); if (ret) goto out_counter_dec; BUG_ON(mirror_num != bioc->mirror_num);But inside btrfs_map_block(), we can modify bioc->mirror_num especiallyfor dev-replace: if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 && !need_full_stripe(op) && dev_replace->tgtdev != NULL) { ret = get_extra_mirror_from_replace(fs_info, logical, *length, dev_replace->srcdev->devid, &mirror_num, &physical_to_patch_in_first_stripe); patch_the_first_stripe_for_dev_replace = 1; }Thus if we're repairing the replace target device, we're going totrigger that BUG_ON().But in reality, the read failure from the replace target device may bethat, our replace hasn't reached the range we're reading, thus we'rereading garbage, but with replace running, the range would be properlyfilled later.Thus in that case, we don't need to do anything but let the replaceroutine to handle it.[FIX]Instead of a BUG_ON(), just skip the repair if we're repairing thedevice replace target device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: tuners: qt1010: replace BUG_ON with a regular errorBUG_ON is unnecessary here, and in addition it confuses smatch.Replacing this with an error return help resolve this smatchwarning:drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- iproute2 > 0-0 (version in image is 4.12-16.6.1).
-
Description: A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be exploited.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libpcap1 > 0-0 (version in image is 1.8.1-10.6.1).
-
Description: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues.This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64 alphabet they are expecting or verify that their application would not be affected if the b64decode() functions accepted "+" or "/" outside of altchars.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- augeas > 0-0 (version in image is 1.10.1-4.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold the array of `struct comedi_insn`, getting the length from the`n_insns` member of the `struct comedi_insnlist` supplied by the user.The allocation will fail with a WARNING and a stack dump if it is toolarge.Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`value is unreasonable.Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add max boundary check for VF filtersThere is no check for max filters that VF can request. Add it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: at_hdmac: fix device leak on of_dma_xlate()Make sure to drop the reference taken when looking up the DMA platformdevice during of_dma_xlate() when releasing channel resources.Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missingput_device() call in at_dma_xlate()") fixed the leak in a couple oferror paths but the reference is still leaking on successful allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- gettext-runtime > 0-0 (version in image is 0.19.2-3.3.6).
-
Description: A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- glib2-tools < 2.48.2-12.58.1 (version in image is 2.48.2-12.46.1).
-
Description: A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.90.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: omap-dma: fix dma_pool resource leak in error pathsThe dma_pool created by dma_pool_create() is not destroyed whendma_async_device_register() or of_dma_controller_register() fails,causing a resource leak in the probe error paths.Add dma_pool_destroy() in both error paths to properly release theallocated dma_pool resource.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,the function jumps to the out_scratch label without freeing the alreadyallocated dsaddrs list, leading to a memory leak.Fix this by jumping to the out_err_drain_dsaddrs label, which properlyfrees the dsaddrs list before cleaning up other resources.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- curl > 0-0 (version in image is 8.0.1-11.108.1).
-
Description: A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libssh-config > 0-0 (version in image is 0.9.8-3.18.1).
-
Description: Modules/_pickle.c in Python before 3.7.1 has an integer overflow via a large LONG_BINPUT value that is mishandled during a "resize to twice the size" attempt. This issue might cause memory exhaustion, but is only relevant if the pickle format is used for serializing tens or hundreds of gigabytes of data. This issue is fixed in: v3.4.10, v3.4.10rc1; v3.5.10, v3.5.10rc1, v3.5.7, v3.5.7rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.7, v3.6.7rc1, v3.6.7rc2, v3.6.8, v3.6.8rc1, v3.6.9, v3.6.9rc1; v3.7.1, v3.7.1rc1, v3.7.1rc2, v3.7.2, v3.7.2rc1, v3.7.3, v3.7.3rc1, v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.158.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.90.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- vim > 0-0 (version in image is 9.1.1629-17.51.1).
-
Description: In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- gpg2 > 0-0 (version in image is 2.0.24-9.14.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-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.43.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: st: Fix array overflow in st_setup()Change the array size to follow parms size instead of a fixed value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (integer underflow or overflow, and application crash) via an ELF file with a corrupt DWARF FORM block, as demonstrated by nm.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: The assign_file_positions_for_non_load_sections function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an ELF file with a RELRO segment that lacks a matching LOAD segment, as demonstrated by objcopy.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: reduce WARN to dev_dbg() in callbackThe warn is triggered on a known race condition, documented in the code abovethe test, that is correctly handled. Using WARN() hinders automated testing.Reducing severity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- python > 0-0 (version in image is 2.7.18-33.53.1).
-
Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()When insert and remove the orangefs module, there are memory leakedas below:unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0Use the golbal variable as the buffer rather than dynamic allocate toslove the problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: amba-pl011: avoid SBSA UART accessing DMACR registerChapter "B Generic UART" in "ARM Server Base System Architecture" [1]documentation describes a generic UART interface. Such generic UARTdoes not support DMA. In current code, sbsa_uart_pops andamba_pl011_pops share the same stop_rx operation, which will invokepl011_dma_rx_stop, leading to an access of the DMACR register. Thiscommit adds a using_rx_dma check in pl011_dma_rx_stop to avoid theaccess to DMACR register for SBSA UARTs which does not support DMA.When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", LinuxSBSA PL011 driver will access PL011 DMACR register in some functions.For most real SBSA Pl011 hardware implementations, the DMACR writebehaviour will be ignored. So these DMACR operations will not causeobvious problems. But for some virtual SBSA PL011 hardware, like Xenvirtual SBSA PL011 (vpl011) device, the behaviour might be different.Xen vpl011 emulation will inject a data abort to guest, when guest isaccessing an unimplemented UART register. As Xen VPL011 is SBSAcompatible, it will not implement DMACR register. So when Linux SBSAPL011 driver access DMACR register, it will get an unhandled data abortfault and the application will get a segmentation fault:Unhandled fault at 0xffffffc00944d048Mem abort info: ESR = 0x96000000 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x00: ttbr address size faultData abort info: ISV = 0, ISS = 0x00000000 CM = 0, WnR = 0swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000[ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP...Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4Code: b9000083 b901f001 794038a0 8b000042 (b9000041)---[ end trace 83dd93df15c3216f ]---note: bootlogd[132] exited with preempt_count 1/etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemonThis has been discussed in the Xen community, and we think it should fixthis in Linux. See [2] for more information.[1] https://developer.arm.com/documentation/den0094/c/?lang=en[2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default < 4.12.14-122.290.1 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid0, raid10: Don't set discard sectors for request queueIt should use disk_stack_limits to get a proper max_discard_sectorsrather than setting a value by stack drivers.And there is a bug. If all member disks are rotational devices,raid0/raid10 set max_discard_sectors. So the member devices arenot ssd/nvme, but raid0/raid10 export the wrong value. It reportswarning messages in function __blkdev_issue_discard when mkfs.xfslike this:[ 4616.022599] ------------[ cut here ]------------[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0[ 4616.236689] Call Trace:[ 4616.239428] blkdev_issue_discard+0x52/0xb0[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00[ 4616.248883] blkdev_ioctl+0x116/0x280[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0[ 4616.257163] do_syscall_64+0x5c/0x90[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690[ 4616.270527] ? do_syscall_64+0x69/0x90[ 4616.274717] ? exc_page_fault+0x62/0x150[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 4616.284748] RIP: 0033:0x7f9a55398c6b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: ISC BIND 9.7.1 through 9.7.2-P3, when configured as an authoritative server, allows remote attackers to cause a denial of service (deadlock and daemon hang) by sending a query at the time of (1) an IXFR transfer or (2) a DDNS update.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.60.2).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: ISC BIND 9.8.x through 9.8.4-P1 and 9.9.x through 9.9.2-P1, in certain configurations involving DNS64 with a Response Policy Zone that lacks an AAAA rewrite rule, allows remote attackers to cause a denial of service (assertion failure and named daemon exit) via a query for an AAAA record.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.60.2).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: libdns in ISC BIND 9.7.x and 9.8.x before 9.8.4-P2, 9.8.5 before 9.8.5b2, 9.9.x before 9.9.2-P2, and 9.9.3 before 9.9.3b2 on UNIX platforms allows remote attackers to cause a denial of service (memory consumption) via a crafted regular expression, as demonstrated by a memory-exhaustion attack against a machine running a named process.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.60.2).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
Description: ISC BIND 9.0.x through 9.8.x, 9.9.0 through 9.9.6, and 9.10.0 through 9.10.1 does not limit delegation chaining, which allows remote attackers to cause a denial of service (memory consumption and named crash) via a large or infinite number of referrals.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.60.2).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- ntp > 0-0 (version in image is 4.2.8p17-106.7.1).
-
Description: Race condition in resolver.c in named in ISC BIND 9.9.8 before 9.9.8-P2 and 9.10.3 before 9.10.3-P2 allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via unspecified vectors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- bind-utils > 0-0 (version in image is 9.11.22-3.60.2).
-
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:
- python > 0-0 (version in image is 2.7.18-33.53.1).
- sles-release == 12.5 (version in image is 12.5-9.5.2).
-
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-release == 12.5 (version in image is 12.5-9.5.2).
- 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-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read()If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely onlpfc_read_object()'s routine to NULL check pdata.Currently, an early return error is thrown from lpfc_read_object() toprotect us from NULL ptr dereference, but the errno code is -ENODEV.Change the errno code to a more appropriate -ENOMEM.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:start_kernel: Add __no_stack_protector function attributeBack during the discussion ofcommit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")we discussed the need for a function attribute to control the omissionof stack protectors on a per-function basis; at the time Clang hadsupport for no_stack_protector but GCC did not. This was fixed ingcc-11. Now that the function attribute is available, let's start usingit.Callers of boot_init_stack_canary need to use this function attributeunless they're compiled with -fno-stack-protector, otherwise the canarystored in the stack slot of the caller will differ upon the call toboot_init_stack_canary. This will lead to a call to __stack_chk_fail()then panic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: allow sleep in qed_mcp_trace_dump()By default, qed_mcp_cmd_and_union() delays 10us at a time in a loopthat can run 500K times, so calls to qed_mcp_nvm_rd_cmd()may block the current thread for over 5s.We observed thread scheduling delays over 700ms in production,with stacktraces pointing to this code as the culprit.qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().Add a "can sleep" parameter to qed_find_nvram_image() andqed_nvram_read() so they can sleep during qed_mcp_trace_dump().qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),called only by qed_mcp_trace_dump(), allow these functions to sleep.I can't tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,so keep b_can_sleep set to false when it calls these functions.An example stacktrace from a custom warning we added to the kernelshowing a thread that has not scheduled despite long needing resched:[ 2745.362925,17] ------------[ cut here ]------------[ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()[ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99[ 2745.362956,17] Modules linked in: ...[ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x[ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020[ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20[ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000[ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000[ 2745.363379,17] Call Trace:[ 2745.363382,17] [] dump_stack+0x8e/0xcf[ 2745.363393,17] [] warn_slowpath_common+0x82/0xc0[ 2745.363398,17] [] warn_slowpath_fmt+0x4c/0x50[ 2745.363404,17] [] ? rcu_irq_exit+0xae/0xc0[ 2745.363408,17] [] do_IRQ+0x15e/0x1a0[ 2745.363413,17] [] common_interrupt+0x89/0x89[ 2745.363416,17] [] ? delay_tsc+0x24/0x50[ 2745.363425,17] [] __udelay+0x34/0x40[ 2745.363457,17] [] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed][ 2745.363473,17] [] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed][ 2745.363490,17] [] qed_mcp_trace_dump+0x4a7/0x630 [qed][ 2745.363504,17] [] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed][ 2745.363520,17] [] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed][ 2745.363536,17] [] qed_dbg_feature_size+0x61/0xa0 [qed][ 2745.363551,17] [] qed_dbg_all_data_size+0x247/0x260 [qed][ 2745.363560,17] [] qede_get_regs_len+0x30/0x40 [qede][ 2745.363566,17] [] ethtool_get_drvinfo+0xe3/0x190[ 2745.363570,17] [] dev_ethtool+0x1362/0x2140[ 2745.363575,17] [] ? finish_task_switch+0x76/0x260[ 2745.363580,17] [] ? __schedule+0x3c6/0x9d0[ 2745.363585,17] [] ? hrtimer_start_range_ns+0x1d0/0x370[ 2745.363589,17] [] ? dev_get_by_name_rcu+0x6b/0x90[ 2745.363594,17] [] dev_ioctl+0xe8/0x710[ 2745.363599,17] [] sock_do_ioctl+0x48/0x60[ 2745.363603,17] [] sock_ioctl+0x1c7/0x280[ 2745.363608,17] [] ? seccomp_phase1+0x83/0x220[ 2745.363612,17] [] do_vfs_ioctl+0x2b3/0x4e0[ 2745.363616,17] [] SyS_ioctl+0x41/0x70[ 2745.363619,17] [] entry_SYSCALL_64_fastpath+0x1e/0x79[ 2745.363622,17] ---[ end trace f6954aa440266421 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix handling of lrbp->cmdufshcd_queuecommand() may be called two times in a row for a SCSI commandbefore it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.See also scsi_send_eh_cmnd().This commit prevents that the following appears if a command times out:WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl logIt's trivial for user to trigger "verifier log line truncated" warning,as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are atleast two pieces of user-provided information that can be output throughthis buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.Verifier log buffer should be properly sized for typical verifier stateoutput. But it's sort-of expected that this buffer won't be long enoughin some circumstances. So let's drop the check. In any case code willwork correctly, at worst truncating a part of a single line output.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: remove BUG_ON()'s in add_new_free_space()At add_new_free_space() we have these BUG_ON()'s that are there to dealwith any failure to add free space to the in memory free space cache.Such failures are mostly -ENOMEM that should be very rare. However there'sno need to have these BUG_ON()'s, we can just return any error to thecaller and all callers and their upper call chain are already dealing witherrors.So just make add_new_free_space() return any errors, while removing theBUG_ON()'s, and returning the total amount of added free space to anoptional u64 pointer argument.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
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.275.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Annotate FDB data racesThe 'used' and 'updated' fields in the FDB entry structure can beaccessed concurrently by multiple threads, leading to reports such as[1]. Can be reproduced using [2].Suppress these reports by annotating these accesses usingREAD_ONCE() / WRITE_ONCE().[1]BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmitwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6fReported by Kernel Concurrency Sanitizer on:CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx231xx: set device_caps for 417The video_device for the MPEG encoder did not set device_caps.Add this, otherwise the video device can't be registered (you get aWARN_ON instead).Not seen before since currently 417 support is disabled, but I foundthis while experimenting with it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().As syzbot reported [0], mpls_route_input_rcu() can be calledfrom mpls_getroute(), where is under RTNL.net->mpls.platform_label is only updated under RTNL.Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() tosilence the splat.[0]:WARNING: suspicious RCU usage6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ----------------------------net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961stack backtrace:CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0a2818e969Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix the setting of capabilities when automounting a new filesystemCapabilities cannot be inherited when we cross into a new filesystem.They need to be reset to the minimal defaults, and then probed foragain.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Remove WARN_ON for device endpoint command timeoutsThis commit addresses a rarely observed endpoint command timeoutwhich causes kernel panic due to warn when 'panic_on_warn' is enabledand unnecessary call trace prints when 'panic_on_warn' is disabled.It is seen during fast software-controlled connect/disconnect testcases.The following is one such endpoint command timeout that we observed:1. Connect =======->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd2. Disconnect ==========->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmdIn the issue scenario, in Exynos platforms, we observed that controltransfers for the previous connect have not yet been completed and endtransfer command sent as a part of the disconnect sequence andprocessing of USB_ENDPOINT_HALT feature request from the host timeout.This maybe an expected scenario since the controller is processing EPcommands sent as a part of the previous connect. It maybe better toremove WARN_ON in all places where device endpoint commands are sent toavoid unnecessary kernel panic due to warn.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- kernel-default > 0-0 (version in image is 4.12.14-122.275.1).
-
Description: Libgcrypt before 1.5.4, as used in GnuPG and other products, does not properly perform ciphertext normalization and ciphertext randomization, which makes it easier for physically proximate attackers to conduct key-extraction attacks by leveraging the ability to collect voltage data from exposed metal, a different vector than CVE-2013-4576.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- libgcrypt20 > 0-0 (version in image is 1.6.1-16.86.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:
- sle-module-adv-systems-management-release >= 12-0 (version in image is 12-4.3.1).
- python-requests > 0-0 (version in image is 2.24.0-8.23.1).
-
Description: A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-9.5.2).
- binutils > 0-0 (version in image is 2.41-9.53.1).